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ABSTRACT 


In  this  thesis  we  investigate  the  high-level  requirements  for  a  concept  system  we 
refer  to  as  Automated  Vehicle  Avoidance  Identification  and  Location  System 
(AVAILS).  The  primary  goal  that  this  system  addresses  is  the  safe  operation  of  large 
ground  vehicles,  operated  by  the  U.S.  Marine  Corps  and  Army,  on  both  military 
reservations  and  public  roadways.  AVAILS  is  comprised  of  an  integrated  collision 
warning  and  collision  avoidance  system.  These  two  subsystems  are  used  to  support 
both  low-speed  docking  and  convoy  operations.  The  objective  is  to  provide  the  driver 
with  real-time  information  that  will  help  him  or  her  act  to  avoid  or  mitigate  the  effects 
of  a  crash  with  another  vehicle  during  convoy  operations,  and  with  another  vehicle  or 
the  docking  facilities  during  docking  operations. 

The  high-level  requirements  for  the  human-computer  interface,  AVAILS-HCI,  are 
discussed  in  the  context  of  the  following:  the  characteristics  of  the  drivers,  the  nature  of 
their  tasks,  the  environment  in  which  ground-based  military  vehicles  operate,  and  the 
doctrine,  policy,  law,  regulations,  and  procedures  which  govern  the  operation  of  such 
vehicles  on  military  reservations  and  public  roadways.  A  high-level  treatment  is  given  of 
the  mapping  of  the  high-level  requirements  for  the  human-computer  interface  to  in- 
vehicle  display  technology,  in  particular,  head-up  displays.  We  developed  a  limited- 
function  prototype  of  the  system  in  order  to  explain  and  reason  about  the  requirements  for 
the  AVAILS-HCI.  We  conclude  the  thesis  with  recommendations  for  future  research. 
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I.  INTRODUCTION 


The  Automated  Vehicle  Identification  and  Location  System  (AVAILS)  is  an 
automated  system  that  will  provide  collision  avoidance  and  collision  warning  capability 
for  ground-based  military  trucks  and  other  heavy  vehicles.  AVAILS  consists  of  an 
interactive  graphical  user  interface  (GUI).  AVAILS  is  primarily  intended  for 
employment  in  military  operations,  although  military  operations  are  often 
indistinguishable  from  commercial  operations  because  many  military  operations  may 
involve  a  large  degree  of  contracted  commercial  services.  The  key  distinction  in  terms  of 
requirements  is  that  AVAILS  must  be  capable  of  operating  wherever  the  United  States 
military  may  deploy. 

AVAILS  consists  of  an  interactive  display  console  with  several  sensor 
components.  The  driver  has  the  capability  to  instantly  configure  certain  aspects  of  the 
system  by  merely  touching  various  menu  options  presented  on  the  display  console.  The 
menu  options  allow  the  driver  to  cause  AVAILS  to  switch  to  a  different  mode  of 
operation,  such  as  for  low-speed  backing  into  a  loading  dock,  or  for  use  in  long-haul 
operations.  If  the  distance  falls  below  the  threshold  for  the  current  mode  of  operation, 
then  either  the  collision  warning  or  collision  avoidance  system  intervenes  to  assist  the 
vehicle  operator  in  re-establishing  an  acceptable  distance  from  the  vehicle  and  other 
objects.  The  post-processed  sensor  data  is  presented  to  the  driver  via  the  AVAILS- 
Human  Computer  Interface  (HCI),  located  in  the  cab  of  the  vehicle.  When  the  driver  of 
one  vehicle  overtakes  another  vehicle,  the  driver  will  visually  know,  by  the  console 
display,  when  it  is  safe  to  complete  the  passing  maneuver  and  change  lanes  in  front  of  the 
overtaken  vehicle.  AVAILS  is  intended  to  assist  DoD  personnel  to  safely  operate  motor 
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transport  vehicles  to  perform  a  variety  of  tasks  under  possibly  adverse  environmental 
conditions  (e.g.,  low  visibility). 

A,  BACKGROUND 

Current  DoD  vehicle  operating  procedures  closely  mirror  standardized 
commercial  procedures,  including  those  for  parking,  vehicle  backing,  and  highway  travel. 
The  National  Traffic  Highway  Safety  Administration  (NTHSA)  influences  many  of 
today’s  vehicle  operating  procedures  and  safety  regulations.  The  NTHSA  adheres  to  the 
procedures  and  guidelines  as  set  forth  by  the  Department  of  Transportation  (DOT). 
While  there  is  no  overall  official  document  dictating  the  rules  of  the  road,  nearly  all  states 
follow  the  intent  of  the  DOT  and  develop  their  highway  driving  laws  and  regulations 
through  each  state’s  department  of  motor  vehicles  (DMV).  As  a  result,  many  military 
facilities  involved  with  operating  vehicles  on  public  roadways,  train  their  vehicle 
operators  in  accordance  with  local,  city,  and  state  highway  laws  and  regulations. 
Operators  of  military  vehicles  receive  training  specific  to  the  type  of  vehicle  they  will 
operate.  That  is  to  say  that  a  potential  crane  or  forklift  operator  is  specifically  trained  to 
safely  operate  a  crane  or  forklift,  on  or  off  military  installations. 

Of  particular  importance  is  the  need  to  avoid  costly  vehicular  mishaps  and 
collisions.  Today,  most  drivers  rely  on  common  driver  courtesy  and  personal  experience. 
While  acquired  driver  experience  may  help  an  individual  to  operate  a  vehicle  in  a 
defensive  manner,  there  are  occasions  in  which  drivers  are  placed  in  unique  and 
precarious  driving  situations.  Many  external  factors,  such  as  driver  fatigue,  road  rage, 
traffic  congestion,  and  unfamiliarity  with  the  driving  environment,  can  influence  how  a 
driver  performs  while  operating  a  vehicle. 
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Moreover,  many  military  motor  transport  operations  ean  involve  eonvoy 
requirements  where  hazardous  materials  are  being  transported  and  vehiele  mishaps  eould 
result  in  substantial  harm  to  people  or  property,  not  to  mention  losses  assoeiated  with 
effieaey,  sueh  as  loss  of  produetivity  or  not  delivering  cargo  to  its  intended  destination  on 
time  to  support  a  mission.  Transport  operations  can  require  the  loading  of  military 
vehicles  on  aircraft  or  ships.  Preparations  for  such  intermodal  loading  operations  can 
require  vehicle  consolidation  and  pre-staging  in  very  confined  areas.  Situations  such  as 
these  are  envisioned  to  be  environments  for  the  employment  of  AVAILS. 

AVAILS  is  a  hybrid  autonomous  system  (i.e.,  there  is  no  communication  between 
vehicles  for  the  purpose  of  coordinating  vehicle  control)  consisting  of  both  a  collision 
warning  system  (CWS)  and  a  collision  avoidance  system  (CAS).  AVAILS  will 
primarily  serve  as  a  CWS.  If  a  driver  attempts  to  park  a  vehicle  in  close  proximity  to 
other  objects,  AVAILS  in  its  CWS  mode,  would  indicate  to  the  driver  which  area  of  the 
vehicle  triggered  the  warning.  Likewise,  if  a  driver  were  required  to  operate  a  vehicle  on 
the  highway,  AVAILS  would  warn  the  driver  if  other  vehicles  traveling  in  the  same 
direction  were  operating  within  pre-set  boundaries  of  the  system.  As  a  CAS,  the  only 
function  of  AVAILS  would  be  to  slow  the  vehicle  if  the  rate  of  closure  to  the  vehicle  in 
front  exceeds  a  safety  threshold;  that  is,  the  CAS  would  function  as  an  adaptive  cruise 
control  system. 

AVAILS  can  best  be  visualized  as  an  interactive  display  console.  The  driver  can 
instantly  configure  certain  aspects  of  the  system  by  merely  touching  various  menu 
options.  The  menu  options  are  used  by  the  driver  to  adjust  some  of  the  AVAILS 
parameters  so  that  the  system  assists  the  driver  in  conforming  to  a  specific  set  of  vehicle 
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operating  procedures.  A  depiction  of  the  vehicle,  and  the  relation  of  other  vehicles  that 
are  being  passed  or  that  are  passing,  will  be  the  primary  image  on  the  console  display. 
Figure  1. 


r - N 
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SETTINGS 

V _ ) 


MESSAGE  BOX 


Figure  1.  AVAILS  Display  Console. 


AVAILS  will  only  provide  collision  warning  and  avoidance  for  traffic  moving  in 
the  same  direction  of  travel.  More  specifically,  AVAILS  is  intended  to  provide 
protection  on  both  sides  of  the  vehicle  to  a  distance  of  one  lane,  as  shown  in  Figure  1. 
Protection  to  the  rear  of  the  vehicle  will  be  dependent  upon  the  information  entered  by 
the  driver.  For  example,  if  the  driver  is  operating  the  vehicle  under  normal  driving 
conditions,  the  commonly  suggested  distance  should  be  one  car  length  for  every  ten  miles 
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per  hour.  Therefore,  if  a  driver  were  traveling  at  a  speed  of  sixty  miles  per  hour,  there 
should  be  a  minimum  rear  distanee  between  vehicles  of  six  car  lengths.  AVAILS  will 
also  provide  forward-looking  proximity  warnings  using  the  same  guidelines. 

Current  DoD  and  commercial  standard  vehicle-operating  procedures  will  be 
examined  along  with  existing  collision  warning  and  collision  avoidance  systems  in  an 
attempt  to  develop  system  requirements  for  a  prototype  of  the  AVAILS-Human 
Computer  Interface  (AVAILS-HCI). 

B,  PURPOSE 

The  overall  purpose  of  this  research  is  to  develop  a  generic  prototype  of 
AVAILS-HCI.  The  intended  purpose  of  AVAILS  is  to  provide  collision  warning  and 
collision  avoidance  during  vehicular  operations  conducted  by  the  United  States 
Department  of  Defense.  As  such,  we  specified  requirements  for  AVAILS  based  upon  the 
following:  current  DoD  standard  operating  procedures;  along  with  current  highway  traffic 
laws,  regulations,  and  protocols;  and  the  functionality  of  existing  collision  warning  and 
collision  avoidance  systems. 

C.  SCOPE 

The  scope  of  this  thesis  is  to  explore  the  development  of  the  user  interface  of 
AVAILS.  As  a  user  interface,  AVAILS  must  be  usable  and  attractive  enough  to  gain 
some  degree  of  trust  from  the  user.  As  a  result,  emphasis  was  placed  on  both  human 
factors  issues  and  the  physical  structure  of  AVAILS.  We  leave  to  future  research,  the 
investigation  of  sensor  technology,  communication  protocols,  and  algorithmic  decision¬ 
making:  these  are  needed  to  assess  the  technical  feasibility  of  realizing  AVAILS. 
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D, 


ORGANIZATION  OF  THE  REPORT 


Chapter  II  describes  the  operating  environment  of  AVAILS.  An  initial  set  of 
requirements  for  AVAILS  are  presented  in  Chapter  III.  In  chapter  IV,  we  examine 
existing  collision  avoidance  and  collision  warning  systems.  Chapter  V,  we  introduce  the 
architectural  framework  of  the  AVAILS-HCI.  We  close  with  the  conclusions  and 
recommendations  for  future  research. 
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II.  AVAILS  OPERATING  ENVIRONMENT 


AVAILS  is  a  system  specifically  designed  for  use  in  military  vehicles.  As  such, 
the  operating  environment  of  AVAILS  will  be  wherever  the  military  may  deploy.  Only 
the  United  States  Army  (U.S.  Army)  and  the  United  States  Marine  Corps  (USMC) 
routinely  operate  convoys  on  the  nation’s  highway  systems.  The  policies  and  procedures 
governing  motor  vehicle  operation  are  nearly  identical  for  each  service.  The  Marine 
Corps  is  usually  the  branch  of  DoD  that  initially  deploys  in  response  to  crisis  situations 
globally.  As  a  result,  military  operations  conducted  abroad  are  usually  governed  in  the 
early  stages  of  deployment  by,  USMC  doctrinal  policy,  and  operating  procedures. 
Therefore,  further  discussions  of  military  and  commercial  operations  will  be  explored 
with  a  preference  toward  Marine  Corps  doctrine,  policy,  and  procedures. 

A,  TRANSPORTATION  DEFINED 

The  Marine  Corps  considers  transportation  as  one  of  the  primary  categories  of 
combat  service  support  (CSS)  [18].  Combat  service  support,  as  a  concept,  provides 
doctrinal  guidance  for  logistic  support  to  every  element  of  the  Marine  Corps.  The  six 
functional  areas  of  operational  logistics  and  combat  service  support  are  as  follows: 
supply,  maintenance,  transportation,  general  engineering,  health  services,  and  general 
services  [17].  The  functional  area  of  transportation  can  be  further  broken  down  into 
embarkation,  landing  support,  port  and  terminal  operations,  air  delivery,  freight  and 
passenger  transportation,  material  handling  equipment,  and  lastly  motor  transport.  The 
Marine  Corps  defines  motor  transportation  as  surface  transportation  using  wheeled 
vehicles.  The  Marine  Corps  considers  motor  transportation  to  be  the  most  versatile  and 
reliable  of  the  six  functional  areas.  Transportation  is  the  cornerstone  to  any  logistical 
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effort,  whether  military  or  eommereial.  Motor  transportation  ean  be  employed  wherever 
there  is  navigatable  terrain.  Motor  transportation  provides  the  erueial  link  to  all  elements 
in  the  operational  battlefield.  That  is  to  say,  motor  transportation  ean  effectively  provide 
links  to  aerial  ports,  seaports,  supply  facilities,  and  forward  deployed  combat  units  [18]. 
In  short,  motor  transportation  provides  the  very  foundation  for  logistics. 

Control  of  motor  transportation,  in  the  Marine  Corps,  is  either  centralized  or 
decentralized  [18].  Centralized  control  of  motor  transportation  assets  supports  the 
interdependency  of  all  the  components  of  the  transportation  category.  There  is  one 
designated  central  support  center  that  controls  all  vehicle  dispatching,  convoy,  and 
logistics  requirements.  In  decentralized  control,  the  independent  tactical  commander  is 
given  control  over  their  motor  transportation  assets. 

B,  MARINE  CORPS  VEHICLES 

The  Marine  Corps  maintains  and  operates  a  wide  range  of  motor  transportation 
equipment.  The  vehicles  are  considered  either  general-purpose  tactical  vehicles  or 
special-purpose  tactical  vehicles  [18].  General-purpose  vehicles  provide  standardized 
transportation  requirements,  while  specialized  vehicles  are  dedicated  to  specific  mission 
requirements.  General-purpose  vehicles  are  further  classified  as  light,  medium,  or  heavy 
vehicles.  As  expected,  light  vehicles  offer  high  mobility  and  are  therefore  ideally  suited 
for  combat  missions.  The  most  highly  utilized  light  vehicle,  in  both  the  Army  and 
Marine  Corps,  is  the  High  Mobility  Multi-purpose  Wheeled  Vehicle  (HMMWV). 

The  HMMWV  is  a  multi-configurable  vehicle  that  is  typically  used  as  the  head  and  tail 
vehicle  for  most  convoys.  Only  four  of  the  many  configurations  of  the  vehicle  are 
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depicted  in  Figure  2.  .  As  a  lead  vehicle  in  a  convoy,  the  HMMWV  would  be  a  prime 


candidate  for  the  AVAILS. 


Figure  2.  HMMVW  (From;  [21]) 


Medium-duty  vehicles  offer  a  high  level  of  tactical  mobility  for  combat 
operations  and  combat  service  support  operation.  Medium-duty  vehicles  can  support  a 
range  of  missions  from  troop  transport,  vehicle  recovery,  fuel  and  water  carrier,  mobile 
maintenance  shops,  and  shelters. 

Like  medium-duty  vehicles,  heavy  vehicles  are  highly  supportive  of  a  wide 
variety  of  missions.  Heavy  vehicles  are  usually  the  vehicles  used  for  massive  convoy 
operations  since  they  typically  carry  the  bulk  of  oversized  cargo.  AVAILS  must  be 
capable  of  supporting  such  vehicles  because  their  unusual  size  and  possibly  dangerous 
cargo  may  require  safe  handling  during  transport. 

Special  purpose  vehicles,  as  their  title  implies,  are  generally  designed  with  a 
specific  purpose  in  mind.  Special  purpose  vehicles  are  themselves  classified  as  light 
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individual  vehicles,  all-terrain  vehicles,  special  operations  vehicles,  and  fire-fighting 
vehicles.  AVAILS  will  be  capable  of  supporting  these  vehicles  too. 

If  AVAILS  will  be  used  to  support  DoD  motor  transportation  assets,  then  it  must 
be  multi-configurable,  flexible,  durable,  and  portable.  As  previously  mentioned,  nearly 
every  classification  of  vehicle  used  by  the  Marine  Corps  is  multi-configurable.  Figure  3 
depicts  some  of  the  medium-duty  and  heavy  vehicles  utilized  by  both  the  Army  and 
Marine  Corps. 


Figure  3.  Medium-duty  and  Heavy  Vehicles  (From;  [21]) 

The  trailer  portion  of  the  vehicles  can  be  attached  or  detached.  The  driver’s 
vehicle  cabin  can  either  be  collapsed  or  expanded.  AVAILS  must  be  versatile  enough  to 
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support  the  majority  of  the  eonfigurations  that  these  vehicles  may  assume.  Figure  4 
depicts  just  a  few  of  the  trailers  that  are  used  by  the  Marine  Corps. 


Figured.  Trailers  (From;  [21]) 


Chapter  IV  contains  a  description  of  several  commercial  intelligent  transportation 
systems  (ITS)  that  support  vehicles  similar  to  those  used  by  the  Marine  Corps. 

C.  MILITARY  AND  COMMERCIAL  OPERATIONS 

Military  operations  involving  motor  transportation  are  dynamic  by  nature.  The 
Marine  Corps  can  be  deployed  by  land,  sea,  or  air.  Each  method  of  deployment  has  some 
unique  requirements.  However,  initial  preparation  for  each  method  involves  pre-staging 
of  motor  transportation  assets.  Pre-staging  is  basically  the  mobilization  and  load 
preparation  of  trucks  and  equipment.  Mobilization  often  involves  parking  vehicles  within 
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inches  of  each  other.  The  same  parking  requirements  exist  whether  these  transportation 
assets  are  loaded  onto  ships  or  aircraft.  Nearly  all  vehicles  arrive  at  pre-staging  by  means 
of  a  convoy.  In  fact,  convoys  are  key  to  any  military  deployment. 

Commercial  operations  are  generally  approached  and  handled  in  the  same  manner 
as  military  operations.  One  major  difference  is  that  commercial  operations  are  more 
likely  to  be  conducted  within  the  United  States,  whereas  military  operations  are 
conducted  nationally  and  internationally. 

D,  MARINE  CORPS  AND  ARMY  CONVOYS 

A  convoy  is  defined  as  a  group  of  vehicles  organized  for  the  purpose  of  control 
and  orderly  movement  of  personnel,  supplies,  and  equipment.  Convoys  are  organized  by 
task  to  meet  the  requirements  of  the  specific  missions.  Convoys  are  always  utilized  to 
transport  troops  and  equipment  from  one  location  to  another.  Convoys  are  highly  utilized 
by  the  U.S.  Army  and  the  Marine  Corps.  Military  convoys  interact  with  civilian  traffic 
on  the  nation’s  public  highways.  Accidents  involving  civilian  and  military  vehicles  are 
highly  undesirable  but  at  times  do  occur.  AVAILS  is  intended  to  minimize  the  risk  of 
crashes  between  military  vehicles  and  between  military  and  non-military  vehicles.  The 
Marine  Corps  utilizes  three  types  of  convoys:  a  march  column,  a  serial  column,  and  the 
march  unit  [18].  Each  type  of  convoy  is  a  derivative  of  a  basic  column,  that  is,  a  linear 
line  of  vehicles.  Differences  among  each  type  of  convoy  are  determined  by  various 
policies  and  procedures  that  are  used  to  govern  the  conduct  convoy  movement. 
Regardless  of  the  convoy  type,  the  common  goal  of  each  convoy  is  the  safe  and  timely 
transport  of  personnel,  supplies,  and  equipment. 
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The  convoy  is  further  broken  down  into  three  subsections:  the  head,  the  main 
body,  and  the  tail.  As  its  name  dictates,  the  convoy  head  controls  the  convoy’s  pace  and 
direction.  The  main  body  typically  transports  the  crucial  supplies  and  equipment.  The 
trail  element  ensures  convoy  security  and  integrity  throughout  the  convoy’s  lifetime. 
Determining  the  vehicles  in  the  convoy  on  which  to  place  AVAILS  is  also  vitally 
important.  The  size,  type,  and  convoy  configuration  are  all  factors  that  must  be 
considered.  However,  it  should  be  quite  plausible  to  consider  placing  AVAILS  on  the 
lead  vehicle  and  the  last  vehicle,  in  the  convoy.  The  lead  vehicle  will  undoubtedly  utilize 
CAS,  if  its  rate  of  closure  to  other  vehicles  were  too  great.  Importantly,  the  last  vehicle 
will  need  to  be  completely  aware  of  any  other  vehicles  in  the  immediate  proximity  before 
it  signals  the  column  to  change  lanes. 

Current  methods  used  for  convoy  communications  are  simplistic  and  effective. 
Convoys  use  a  system  of  flags  or  lights  and  movement  control  numbers  for  identification. 
In  peacetime  operations,  all  convoys  are  required  to  travel  with  low-beam  headlights. 
The  convoy  commander,  and  local  policies  and  regulations  of  the  highways  being  used, 
nearly  always  dictate  convoy  movement.  In  an  attempt  to  control  convoy  movement, 
convoys  have  assumed  three  formations:  close  column,  open  column,  and  infiltration. 
The  close  column  allows  each  vehicle  to  follow  the  vehicle  to  the  front  at  a  distance  that 
minimizes  the  chance  of  a  collision.  In  the  open  column,  vehicle  distance  is  increased  to 
enhance  dispersion.  In  an  infiltration,  small  batches  of  vehicles  are  dispersed  randomly 
in  an  effort  to  control  traffic  congestion.  In  each  of  these  instances,  there  may  be  several 
lead  and  trail  vehicles  that  can  all  benefit  from  AVAILS. 
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E, 


SAFETY  ISSUES 


In  recent  decades,  safety  has  moved  to  the  forefront  of  DoD’s  doctrinal 
procedures.  Every  service  component  of  DoD  has  an  official  safety  program.  One  major 
aspect  of  each  program  is  devoted  to  motor  vehicle  safety.  Army  Regulation  190-5, 
Operational  Naval  Instruction  (OPNAV)  11200.5C,  Air  Force  Regulation  125  -  14, 
Marine  Corps  Order  51 10. 1C,  and  Defense  Logistics  Agency  5720.1,  represents  a  joint 
doctrinal  publication  which  outlines  all  aspects  of  motor  vehicle  regulation  [15].  The 
document  is  titled  “Motor  Vehicle  Traffic  Supervision  As  previously  stated,  nearly  all 
aspects  of  motor  vehicle  safety  and  regulation  are  addressed  in  this  document.  The 
document  will  undoubtedly  prove  beneficial  in  formulating  a  few  of  the  system 
requirements  for  AVAILS.  The  Insurance  Institute  for  Highway  Safety  maintains 
statistical  data  concerning  highway  incidents  and  vehicle  safety  [27]. 

Large  trucks  comprise  a  huge  portion  of  DoD’s  motor  transportation  assets.  A 
large  truck,  whether  military  or  commercial,  poses  a  significant  risk  on  the  highway.  Due 
to  their  frequency  of  travel,  large  trucks  have  accounted  for  more  than  their  share  of 
highway  fatalities.  Tractor-trailers  have  a  higher  fatal  crash  rates  per  mile  than  passenger 
vehicles  [6].  In  1999,  5,282  people  died  in  crashes  involving  large  trucks.  Sixty  percent 
of  1999  deaths  in  large  truck  crashes  occurred  on  major  roads  while  twenty-nine  percent 
occurred  on  freeways  and  ten  percent  occurred  on  minor  roads.  Ninety-eight  percent  of 
fatalities  involving  two-vehicles  between  large  trucks  and  passenger  vehicles  were  the 
occupants  of  the  passenger  vehicle.  These  facts  were  obtained  from  the  United  States 
Department  of  Transportation’s  Fatality  Analysis  and  Reporting  System  (LARS),  [6]. 
While  it  is  not  immediately  obvious  how  many  of  the  large  trucks  were  military  vehicles. 
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these  facts  clearly  support  the  concept  of  AVAILS.  Figure  5  list  statistics  spanning  a 


twenty-five  year  history  of  large  truck  crash  fatalities. 


DEATHS  IN  LARGE  TRUCK  CRASHES 


Tractor- 

Trailer 

Occupania 

Truck 

Type 

Unknown 

Paaaenger 

Vehicle 

Occupanta 

Other  or 
Unknown 
Vehicle 

Nonoccupant 

Deaths 

Total 

1975 

660 

162 

94 

2,757 

104 

528 

4,305 

1976 

809 

291 

0 

3,071 

100 

622 

4,893 

1977 

915 

231 

83 

3.631 

101 

653 

5.614 

1978 

968 

251 

96 

3,954 

115 

776 

6,160 

1979 

1,008 

282 

82 

4.226 

111 

830 

6.539 

1980 

867 

234 

82 

3.623 

90 

844 

5.740 

1981 

832 

186 

64 

3.752 

74 

772 

5,680 

1982 

720 

141 

56 

3.448 

81 

679 

5,125 

1983 

733 

132 

95 

3,615 

97 

732 

5.404 

1984 

853 

125 

62 

3.713 

85 

712 

5,550 

1985 

747 

123 

71 

3.825 

123 

724 

5.613 

1986 

689 

139 

64 

3,752 

106 

718 

5,468 

1987 

654 

112 

55 

3,833 

105 

712 

5.471 

1988 

706 

119 

61 

3.938 

95 

647 

1989 

643 

116 

63 

3.847 

104 

587 

5.360 

1990 

503 

126 

55 

3,790 

85 

615 

5,174 

1991 

448 

130 

72 

3.447 

69 

562 

4,728 

1992 

412 

136 

32 

3,300 

61 

481 

4,422 

1993 

423 

142 

25 

3,611 

115 

462 

4.778 

1994 

453 

165 

40 

3.764 

92 

555 

5.069 

1995 

443 

168 

23 

3.626 

79 

495 

4,834 

1996 

426 

149 

27 

3.866 

115 

465 

5.048 

1997 

481 

196 

40 

3,992 

89 

497 

5.295 

1998 

501 

212 

26 

3.981 

101 

495 

5,316 

1999 

536 

189 

21 

3.907 

119 

510 

5.282 

Figure  5.  Death  Rate  for  Large  Truck  Crashes  (From;  [6]) 


One  column  of  particular  interest  is  the  “Passenger  Vehicle  Occupants”  column.  This 
column  represents  the  number  of  people  killed  in  an  accident  involving  a  large  truck. 
The  exact  cause  of  each  crash  varies  greatly,  but  undoubtedly  many  of  the  accidents 
occurred  because  the  truck  driver  simply  did  not  see  the  passenger  vehicle. 
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Figure  6  offers  a  look  into  the  number  of  deaths  and  the  truek  eonfiguration.  By 
truek  eonfiguration  it  is  meant  that  the  truek  either  was  attaehed  or  unattaehed  to  a  trailer 
unit.  The  greatest  number  of  fatalities  oeeurred  when  the  truck  has  a  trailer  attached. 


DEATHS  IN  LARGE  TRUCK  CRASHES 

BY  TRUCK  CONFIGURATION,  1999 

Tractor-trailer 

3,888 

Single-unit  truck 

1,373 

Unknown  truck  configuration 

140 

Total 

5,282 

Figure  6.  Truck  Configuration  (From;  [6]) 


Figure  7  lists  the  fatalities  based  on  the  type  of  highway  used  by  large  trucks.  As 
expected,  major  roads  account  for  the  greater  number  of  crash  fatalities.  These  roads  are 
traveled  by  a  large  number  of  passenger  vehicles  and  large  trucks  traveling  together. 


DEATHS  IN  LARGE  TRUCK  CRASHES  BY  HIGHWAY  TYPE,  1999 

Minor  Roads 

Unknown 

Total 

Single-vehicle  crashes 

186 

209 

64 

4 

463 

Multiple-vehicle  crashes 

1,167 

2,647 

334 

42 

■Em 

Crashes  with  pedestrians, 
bicyclists,  motorcyclists 

146 

249 

108 

7 

510 

Other/unknown 

33 

63 

22 

1 

119 

Figure  7.  Truck  Crashes  by  Highway  Type  (From;  [6]) 


Naturally  DoD  desires  to  limit  the  number  of  crash  fatalities  involving  its  large 
trucks.  Military  vehicles  and  convoys  pose  a  significant  risk  to  each  other  and  non¬ 
military  vehicles  in  terms  of  crash  severity.  The  Marine  Corps  attributes  motor  vehicle 
accidents  to  the  following  four  factors;  speed,  pre-occupation,  fatigue,  and  drugs  and 
alcohol.  The  Marine  Corps  and  DoD  for  that  matter,  seeks  to  deter  motor  vehicle 
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incidents  through  aggressive  motor  vehicle  safety  programs,  vehicle  operator  training, 
and  vehicle  maintenance  and  inspections. 

Every  component  of  DoD  has  an  active  safety  program  to  include  Internet  sites 
and  an  officially  designated  safety  headquarters  location.  Motor  vehicle  and  traffic  safety 
are  a  major  issue  in  each  of  these  safety  programs.  The  Army  maintains  an  Internet  site 
called  Safety  and  Health  Resources  ('http://safetv.armv.mil/pages/links/index.html)  [36], 
where  it  lists  dozens  of  links  to  a  majority  of  DoD’ s  safety  related  Internet  sites. 

The  Marine  Corps  attacks  safety  very  aggressively.  Marine  Corps  units  are 
mandated  to  adhere  to  regulations  set  forth  by  the  Occupational  Safety  and  Health 
Administration  (OSHA)  [20].  Additionally,  every  Marine  Corps  unit  is  required  to  have 
a  “safe  driving  council”[19].  The  purpose  of  the  safety  program  is  to  assist  the 
commanding  officer  in  establishing  and  maintaining  a  vehicle  mishap  prevention 
program.  In  short,  traffic  safety  begins  before  the  driver  enters  their  vehicle.  Vehicles 
operators  are  not  allowed  to  enter  a  vehicle  unless  they  are  in  good  mental  and  physical 
condition.  Special  attention  is  given  to  the  frequency  of  use  of  a  particular  driver. 
Operators  are  briefed  on  their  routes,  checkpoints,  and  points  of  contacts  prior  to 
operating  a  vehicle.  Operators  are  provided  detailed  maps  indicating  specific  routes. 
More  importantly,  operators  are  made  aware  of  road  and  weather  conditions,  including 
probable  forecasted  changes  [18]. 

AVAILS,  in  concept,  will  provide  an  extra  perimeter  of  safety  for  motor  vehicle 
operators.  In  addition  to  being  made  aware  of  vehicles  in  their  proximity,  vehicle 
operators  will  be  allowed  to  adjust  their  vehicle’s  perimeter  of  safety  based  upon  weather 
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conditions.  The  weather  module  in  AVAILS  takes  into  account,  daytime  and  nighttime 
eonditions,  as  well  as  rain,  fog,  sleet  and  snow. 
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III.  AVAILS-HCI  REQUIREMENTS 


A,  HUMAN  COMPUTER  INTERACTION  (HCI) 

Human-computer  interaction  (HCI)  is  an  integral  issue  to  be  addressed  in  the 
design  of  information  systems.  If  the  user  of  the  information  systems  judges  the  HCI  to 
be  too  difficult  or  cumbersome  to  use,  then  he  or  she  may  turn  off  the  HCI  or  the  entire 
system,  resulting  in  the  effectiveness  of  the  information  system  being  zero.  There  are  a 
host  of  issues  that  must  be  considered  when  designing  a  human  computer  interface. 

The  psychological  effect  must  be  such  that  the  user  has  a  high  degree  confidence  in  the 
interface  and  in  their  ability  to  use  it  to  complete  tasks.  The  human  user  must  have 
some  confidence  that  the  system  will  perform  as  expected,  if  not  better  than  expected. 

At  the  same  time,  the  user  should  not  totally  rely  on  software.  The  primary  question  we 
address  is  what  are  the  requirements  for  the  AVAILS-HCI?  In  addition  to  these  issues, 
there  are  concerns  about  the  operational  benefits,  safety  related  factors,  and  the  pro  and 
cons  of  Heads-Up-Displays  (HUD).  Due  to  the  fact  that  we  treat  the  AVAIL-HCI  at  an 
abstract  level,  we  will  answer  the  preceding  question  in  general  terms  based  on  the 
functional  requirements  for  collision  warning  and  avoidance.  We  leave  the  detailed 
analysis  of  the  HCI  design  to  future  work,  which  would  entail,  among  other  things,  a 
task  analysis  to  be  conducted. 

1.  What  is  Human  Computer  Interaction  (HCI)? 

Human-computer  interaction  is  the  way  in  which  a  user  interacts  with  a  computer- 
based  system.  Human  factors  is  the  engineering  discipline  that  addresses  the  design  of 
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systems  to  accommodate  the  needs  of  users.  Let  us  begin  our  discussion  of  HCI,  in  the 
context  of  information  systems,  with  some  examples.  A  simple  example  is  a  pointing 
device  in  a  windows  environment,  which  may  be  elementary  to  learn  to  use  by  some 
users  of  software  applications,  but  difficult  for  others.  For  instance,  if  someone  working 
in  a  graphical  design  shop  has  to  grab  and  pull  items  to  construct  an  object,  their 
visualization  of  a  hand  that  grips  and  carries  the  object  to  where  the  user  wants  it  to  be 
placed  in  the  virtual  workspace  may  be  more  intuitive  to  that  particular  type  of  user.  If 
the  user  happens  to  be  a  graphical  artist  and  uses  a  pointing  device  to  draw,  there  are 
several  scenarios  for  that  pointing  device  that  the  user  may  be  more  comfortable  with 
such  as  a  paintbrush,  marker,  or  pencil  image  vice  just  having  a  tip  on  an  arrow  as  a 
pointer. 

Pointing  devices  are  just  the  tip  of  the  iceberg  when  it  comes  to  HCI.  The 
graphical  layout  of  a  computer  screen  or  the  program  itself  can  influence  how  a  user  will 
interact  with  the  system.  If  the  colors  are  too  bright  then  those  colors  may  disorient  the 
user,  or  if  they  are  too  plain  it  may  disinterest  the  user.  These  are  simple  examples  but 
are  potentially  be  major  factors  in  the  development  of  a  system  and  the  effective  use  of 
the  system.  Nielsen  [11]  introduced  the  following  heuristics  regarding  usability  as  it 
pertains  to  HCI: 

•  Simple  and  Natural  Dialogue  -  Using  an  automobile  collision-detection  alarm- 
system  application  as  an  example,  it  would  not  be  practical  to  flash  a  green  light 
when  the  vehicle  is  about  to  hit  something.  Any  user  with  driving  experience  in 
the  United  States  would  rather  have  a  red  light  for  stop,  a  yellow  light  for 
exercising  caution  and  a  green  light  for  go.  Our  society  has  developed  certain 
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perceptions  that  may  not  be  universal  but  certainly  easily  recognizable  by  a  grand 
majority. 

•  Speak  the  User’s  Language  -  Using  the  same  example  as  above,  verbalizing,  “The 
driver  is  1.2  meters  from  the  encroachment  on  space  of  an  unanimated  object”,  is 
not  the  way  the  majority  of  drivers  (especially  truck  drivers)  would  talk.  Direct 
statements  such  as  “Please  stop  the  vehicle,  you  are  about  to  crash  into  something 
on  your  rear  left  side”  would  be  much  more  user  friendly  and  understandable. 

•  Minimize  User  Memory  Load  -  The  user  should  not  have  to  memorize  several 
screens  in  order  to  accomplish  a  task.  Everything  that  the  user  needs  to  make  an 
informed  decision  should  be  on  the  page  or  in  the  view  of  the  user  at  one  time. 
Putting  trust  in  someone’s  memory  to  make  a  major  decision  could  have 
disastrous  results  and  therefore  should  be  avoided.  A  user  interface  should  be 
designed  to  enhance  the  users  ability  to  make  a  decision  rather  than  hinder  it. 

•  Be  Consistent  -  Being  consistent  covers  several  areas  including  the  color  scheme 
as  well  as  how  the  system  interacts  with  the  user.  If  verbal  messages  are  being 
utilized  then  they  should  be  the  same  or  if  you  use  different  tones  to  show  the 
sensitivity  of  an  action  then  it  should  be  known  upfront  and  should  be  strictly 
adhered. 

•  Provide  Feedback  -  The  user  must  know  whether  something  is  going  on  or  not. 
For  instance  in  most  Microsoft  Windows  applications,  when  the  processor  is  busy 
it  will  show  an  hourglass  to  tell  that  the  system  is  busy  but  working.  This  same 
concept  would  be  used  in  a  vehicle  collision  system,  as  in  the  example  given 
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earlier,  where  the  sereen  would  have  some  blinking  deviee  or  some  other 
notieeable  but  not  annoying  signal  to  let  the  user  know  the  system  is  armed  and 
working. 

•  Provide  Shorteuts  -  The  user  should  have  the  ability  to  retrieve  embedded 
information  or  sereens  without  going  through  a  large  amount  of  sereens  to  get  to 
the  needed  information  or  funetion. 

In  regard  to  audible  warnings,  eonsideration  must  be  given  to  the  type  of  voiee 
that  is  used  in  a  warning.  Some  synthesized  voiees  can  be  annoying  or  not  recognizable. 
If  the  intonation  is  incorrect,  then  the  speech  will  be  unintelligible  to  the  user.  Some 
would  describe  digital  language  as  machinelike,  choppy,  harsh,  grainy,  and  lacking  co¬ 
articulation  (i.e.,  blending  of  words)  and  natural  intonation  [12].  Some  guidelines  for 
synthesized  speech  developed  from  experience  with  designing  real-world  systems  are  as 
follows  [12]; 

•  Voice  warnings  should  be  presented  in  a  voice  that  is  qualitatively  different  from 
other  voices  that  will  be  heard  in  the  situation. 

•  If  synthesized  speech  is  used  exclusively  for  warnings,  there  should  be  no  alerting 
tones  before  the  voice  warning. 

•  If  synthesized  speech  is  used  for  other  types  of  information  in  addition  to 
warnings,  some  means  of  directing  attention  to  the  voice  warning  might  be 
required. 

•  Maximize  intelligibility  of  the  messages. 
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•  For  general-purpose  use,  maximize  user  acceptance  by  making  the  voice  as 
natural  as  possible. 

•  Give  the  user  the  ability  to  interrupt  the  message;  this  is  especially  important  for 
experienced  users  who  do  not  need  to  listen  to  the  entire  message  each  time  the 
system  is  used. 

•  Provide  an  introductory  or  training  message  to  familiarize  the  user  with  the 
system’s  voice. 

•  Do  not  get  caught  up  in  “high-tech  fever.”  Use  synthesized  speech  sparingly  and 
only  where  it  is  appropriate  and  acceptable  to  the  users. 

This,  like  many  other  aspects  of  the  development  of  systems,  depends  on  the 
user’s  likes  and  dislikes. 

2,  How  does  HCI  affect  AVAILS? 

The  effectiveness  of  AVAILS  at  assisting  the  driver  in  avoiding  crashes  is 
dependent  to  some  degree  on  the  design  of  its  HCI.  This  is  why  the  potential  users  of 
AVAILS  need  to  be  involved  in  the  initial  development  of  any  system  to  ensure  that  it 
meets  the  user’s  requirements.  Although  some  degree  user  input  was  utilized  on  the 
initial  conceptual  design  of  the  AVAILS-HCI,  we  relied  on  our  knowledge  of  ground 
transport  by  the  Marine  Corps. 

In  development  of  AVAILS  consideration  has  been  made  on  the  delivery  and  look 
and  feel  of  the  system,  which  will  affect  the  interaction  between  the  user  and  the  system. 
Although  there  may  be  several  ways  to  deliver  the  system  to  the  users,  Head-Down 
Display  (HDD)  and  Head-Up  Display  will  be  the  primary  focus  of  this  study. 


23 


3. 


Head-Down  Display  (HDD) 


HDDs  are  traditionally  used  in  automobiles.  These  are  the  deviees  that  are 
eurrently  loeated  on  the  dashboard  or  somewhere  that  is  not  in  the  driver’s  immediate 
field-of-view  (FOV)  [5].  If  a  deviee  is  plaeed  where  the  user  has  to  look  down  or  away 
from  the  foeus  of  primary  interest,  the  deviee  is  known  as  a  HDDs.  For  example,  the 
speedometer  and  taehometer  are  often  part  of  a  HDD  in  passenger  vehicles,  buses,  and 
trucks.  There  are  also  high-head-down-displays  (HHDD).  HHDDs  are  typically  mounted 
above  the  driver  or  operator  of  the  vehicle  [10].  These  devices  are  similar  to  HDDs 
because  it  makes  the  driver  look  above  the  FOV.  Both  of  these  techniques  are  considered 
older  technology  but  are  explored  as  a  possible  implementation  for  AVAILS. 

4,  Head-Up  Display  (HUD) 

The  Heads-Up  Display  (HUD)  is  the  term  used  for  in-dash  or  windshield  displays 
that  may  be  used  by  pilots  or  drivers  of  automobiles  to  assist  them  in  navigating  or 
operating  their  vehicle  without  having  to  take  their  focus  off  the  FOV  [22].  AVAILS 
could  also  be  developed  as  a  HUD  because  of  its  possible  position  in  the  FOV  of  the 
users  operating  the  vehicle  and  because  of  the  way  the  users  will  utilize  it.  One  major 
difference  between  a  HUD  and  a  HDD  lies  in  the  location  of  the  device  in  the  driver’s 
environment. 


a.  Operational  Considerations 

The  test  results  from  the  study  of  a  HUD  speedometer  indicated  that  70 
percent  of  the  drivers  felt  that  the  HUD  was  easier  to  use  and  more  comfortable  than 
HDD  speedometers  [14].  The  study  also  showed  that  subjects  were  more  aware  of  their 
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speeds  and  were  able  to  maintain  the  posted  speed  limits.  Unfortunately,  when  a 
eomparison  is  made  between  the  manufacturing  costs  for  traditional  speedometers  and 
HUD  technology,  the  HDD  speedometers  are  far  less  expensive. 

At  present,  vehicles  are  not  equipped  with  collision  warning  or  avoidance 
technology.  The  use  of  a  HUD  gives  the  driver  immediate  information  without  the 
operator  having  to  take  his  eyes  off  the  road  or  the  view  they  currently  are  fixed  on.  With 
information  readily  available  in  the  driver’s  view,  the  time  taken  in  redirecting  gaze  and 
refocusing  when  using  an  HDD,  in  theory,  should  theoretically  be  reduced  with  the  use  of 
a  HUD  [22].  Ninety  percent  of  all  input  to  the  driver  is  obtained  via  direct  vision.  The 
reliance  on  vision  can  make  it  difficult,  for  instance,  for  the  driver  to  monitor  a  HDD 
[13].  When  traffic  is  heavy,  the  roadway  is  unfamiliar  to  the  driver. 

b.  Safety  Considerations 

The  AVAILS  HUD  is  intended  to  assist  the  driver  to  make  decisions  by 
providing  information  to  the  driver  about  his  or  her  vehicle’s  proximity  to  other  vehicles. 
The  distance  to  other  vehicles  is  reported  to  the  AVAILS  HUD  by  a  set  of  sensors,  which 
in  combination  have  a  360-degree  FOV.  The  sensors  must  be  able  to  sense  other  vehicles 
at  a  distance  equal  to  or  greater  than  the  minimum  safe  separation  distance  to  the  sensed 
vehicle  and  the  additional  distance  needed  to  permit  AVAILS  to  do  the  following: 
acquire  the  target  vehicle,  track  its  closing  rate,  process  the  input  data,  display  the 
proximity  information  to  the  driver  via  a  HUD,  and  provide  the  driver  with  enough  time 
to  react  to  the  information. 
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A  HUD  is  supposed  to  be  setup  in  the  drivers  primary  FOV  so  that  it  does 
not  take  the  drivers  attention  away  from  the  roadway  [7].  Some  of  the  safety  eoneerns 
are  as  follows:  preventing  the  loss  of  all  displayed  information  due  to  a  ehange  of  the 
driver’s  head  position,  designing  graphies  for  maximum  comprehensibility  and  minimum 
confusion  with  elements  in  the  real  world,  ensuring  clear  visibility  of  display  and  outside 
scene,  establishing  the  right  moment  for  presenting  or  updating  information  and  assessing 
the  acceptance  of  the  system  with  the  intended  users  [7]. 

The  AVAILS  HUD  is  intended  to  enhance  the  driver’s  ability  to  drive 
safely.  If  the  system  interrupts  the  user  or  is  in  some  way  difficult  to  use,  then  it  detracts 
from  the  safety  of  the  operation  of  the  vehicle.  The  measure  of  effectiveness  of  the  HUD 
in  terms  of  safety  will  be  zero  if  the  driver  turns  the  system  off.  This  measure  will  be  low 
if  the  information  is  not  timely  (i.e.,  updated)  enough  to  prevent  a  crash  or  the  display 
distracts  the  driver  in  such  a  way  to  contribute  to  a  crash.  The  measure  of  effectiveness 
will  likely  be  high  otherwise. 

c.  Advantages,  Disadvantages  and  Concerns  of  HUD 

There  are  advantages  as  well  as  disadvantages  to  the  use  of  a  HUD. 
Possible  advantages  include: 

1 .  Augmented  eyes-on-the-road  measure  -  In  contrast  to  an  HDD,  the 
HUD  permits  the  driver  to  view  vital  information  while  his  or  her  attention  is  still 
on  the  roadway.  For  example,  if  the  user  looked  down  to  check  the  vehicle’s 
current  speed  and  anther  vehicle  enters  the  intersection  fifty  meters  ahead.  With 
the  HUD  the  user’s  eyes  are  not  off  the  road,  therefore  providing  the  driver  with 
time  to  react  in  such  a  scenario  [37]. 
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2.  Readjusting  to  FOV  -  HDDs  display  information  approximately 
thirty  inches  from  the  driver  while  HUDs  are  displayed  somewhere  between  1.5 
to  6  meters  away  from  the  driver.  Studies  of  aircraft  HUDs  demonstrated 
improvements  in  re-accommodation  time,  which  means  the  operators  can  respond 
ably  to  blurry  images  [3].  These  studies  are  controversial  because  of  the  mean 
age  of  the  subjects,  which  was  21.9  years  of  age.  Young  drivers  may  be  able  to 
respond  to  visual  stimuli  before  fully  accommodating  to  it.  The  users  of  the 
AVAILS-HCI  are  expected  to  range  in  age  between  nineteen  and  twenty-six  years 
old.  Officers  and  senior  enlisted  personnel  rarely  operate  large  military  vehicles. 
The  target  age  of  AVAILS-HCI  operators,  to  some  degree,  makes  the  “age 
controversy”  a  moot  issue. 

Some  disadvantages  of  a  HUD  include  [1]; 

•  Luminance  may  be  a  limiting  factor  in  the  automobile  due  to  the  presence  of 
glare. 

•  Stringent  cost  constraints  to  install  the  HUD  with  the  optimal  configuration  could 
be  a  challenge  because  the  minimum  standards  represent  a  tradeoff  with  safety. 

•  A  HUD  that  is  too  dim  would  be  worse  than  an  in-dash  display. 

•  The  fact  that  a  driver  is  looking  forward  does  not  mean  that  the  driver  is  able  to 
effectively  process  the  information  in  all  driving  scenarios. 

Most  of  the  challenges  of  concern  deal  with  the  operator’s  ability.  Most  pilots  go 
through  extensive  training  and  have  an  ability  to  comprehend  many  different  things  at  the 
same  time,  at  a  high  level.  One  cannot  assume  that  the  average  driver  of  military 
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transport  vehicles  have  the  same  qualities  and  level  of  training  as  a  pilot.  Although  HUD 
technology  is  well  accepted  for  use  by  pilots,  one  must  take  into  consideration  the 
variations  in  the  population  of  military  personnel  trained  to  operate  military  transport 
vehicles.  The  average  automobile  driver’s  attention  is  a  major  issue  when  talking  about 
in-vehicle  instrumentation  and  their  ability  to  manage  their  concentration.  The  driver 
must  be  able  to  keep  focus  and  not  let  the  amount  of  information  available  from  a  HUD 
distract  him  or  her  or  keep  the  driver  from  the  primary  tasks  associated  with  driving  [2]. 
What  this  means  is  that  extensive  training  will  have  to  be  offered  in  order  for  a  new 
system  to  work  and  be  useful.  Military  personnel  will  have  to  be  trained  to  use  HUD  and 
encouraged  to  embrace  this  and  other  types  of  intelligent  transportation  systems. 
Systems  must  be  ergonomically  correct  and  adjustable  to  ensure  the  system  fits  the  user 
and  not  the  user  trying  to  fit  the  system  [28]. 

5,  Head-Up  Display  Examples 

a.  HUD  Use  in  the  Civilian  Sector 

There  are  several  examples  in  the  civilian  sector  of  the  use  of  HUDs. 
Some  of  the  HUDs  for  use  in  civilian  passenger  vehicles  are  designed  to  project 
information  currently  available  in  HDD  form,  such  as  speed  and  engine  information  to 
the  operator.  General  Motors  (GM)  has  an  exclusive  patent  on  a  HUD  that  allows  the 
operator  to  view  the  speedometer,  tachometer,  water  temperature,  oil  pressure,  fuel  level, 
and  turn  signal  [24].  This  technology  was  first  tested  in  the  Chevrolet  Corvette,  which,  at 
one  time,  gave  it  the  label  of  “The  most  intelligent  car  you’ve  ever  driven.”  GM  based  its 
design  on  the  HUDs  used  in  aircraft.  Sixty-two  percent  of  the  buyers  of  corvette  opted  to 
purchase  the  HUD  option.  In  GM’s  system,  the  operator  can  choose  what  is  to  be 
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displayed  via  the  Driver  Information  Center  (DIC),  whieh  is  loeated  below  the  gauge 
eluster.  The  DIC  is  also  eapable  of  displaying  information  in  several  different  languages, 
ineluding  English,  German,  Freneh  and  Spanish,  and  the  operator  is  able  to  display  in 
English  or  metrie  units  as  well  [24],  GM  ealls  their  display  system  EyeCue.  EyeCue  is 
also  available  on  the  Pontiae  Bonneville  SSE,  Grand  Prix  and  the  Park  Avenue. 

Before  GM  eame  out  with  these  eomfort  upgrades  eomputer  programmers 
were  eoming  up  with  ideas  for  the  network  vehiele  of  the  future.  The  Network  Vehiele, 
first  displayed  at  COMDEX  ’97  in  Eas  Vegas,  November  16-21  1997,  ineluded  deviees 
with  features  sueh  as  the  following: 

•  Separate,  advaneed  driver  and  passenger  displays  with  flat  panel,  toueh  screen 
technology  and  both  keyboard  and  voice  command  entry 

•  A  driver  side,  re-configurable,  voice-command  HUD  in  the  windshield 

•  A  simulated  navigation  system  with  traffic  updates  for  real-time  route  guidance 

•  Hughes  Electronics’  DirecTV  and  DirectPC  satellite  links 

•  Text-to-speech  audio  delivery  of  practically  all  onboard  and  broadcast 
information 

•  Docked  IBM  WorkPad  PDA 

This  vehicle  was  designed  in  a  collaborative  fashion  by  IBM,  Netscape, 
Sun  Micro-systems  and  Delco  Electronics,  provided  the  system’s  processors,  audio  and 
video  equipment,  high-speed  fiber-optic  Mobile  Media  link,  touch-screen  re-configurable 
ECD  displays,  HUD,  and  software  specifications.  Java  was  used  to  integrate  the  different 
technologies  [23]. 


29 


Initially  the  predominant  use  of  HUD  was  being  used  to  display  eurrent 
information  in  the  HUD,  but  today  there  are  several  vehicle  manufacturers  that  are 
thinking  innovatively  and  looking  to  enhance  the  different  types  of  information  they  can 
provide  to  the  user.  For  instance,  GM  is  set  to  offer  a  night  vision  system  for  the  Cadillac 
Deville  that  will  allow  the  driver  to  see  up  to  five  times  further  down  a  dark  road  by  using 
infrared  sensors  [28].  This  information  would  be  displayed  via  a  HUD  and  enable  the 
driver  to  react  quickly  to  looming  surprises  down  the  road  or  to  enhance  their  vision  of 
the  road  on  very  dark  streets  or  in  poor  weather  conditions  [28].  This  vision 
enhancement  system  (VES)  will  also  have  additional  sensors  for  information  such  as 
digital  maps  and  special  installations  to  direct  headlights  to  certain  areas  of  the  road. 

Daimler  Chrysler  researchers  in  Ulm,  Germany  have  also  developed  an 
infrared  laser  night  vision  system  that  significantly  enhances  the  driver’s  night  visibility. 
The  system  enables  the  driver  to  see  darkly  clothed  individuals  or  even  cyclists  at  great 
distances.  It  also  has  an  option  to  illuminate  the  road  500  feet  in  front  of  the  vehicle,  vice 
the  average  of  conventional  high-beam  lights  of  130  feet,  without  blinding  the  drivers  of 
oncoming  vehicles.  Their  system  uses  a  video  camera  to  record  the  reflected  image  and 
then  send  it  to  a  black  and  white  screen  located  in  the  driver’s  FOV.  Initial  tests  of  the 
system  were  performed  on  buses,  but  plans  to  test  this  system  in  trucks  transporting 
hazardous  materials,  emergency  service  vehicles,  and  taxis.  Daimler  Chrysler  has 
targeted  the  development  of  this  system  on  vehicles  that  require  high  levels  of  safety 
[37]. 

In  the  European  Darwin  Project,  for  automotive  Visual  Enhancement 
Systems  (VES),  there  has  been  a  study  of  the  use  of  HUDs  to  assist  the  driver  in  poor 
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visibility  conditions.  This  system  uses  an  infrared  sensor,  operating  in  the  speetral 
wavelength  range  of  eight  to  fourteen  mierons,  whieh  is  eapable  of  deteeting  thermal 
radiation  emitted  by  all  objeets  within  a  eertain  seenario.  Developed  by  the  Boeing 
Corporation,  the  system  eonsists  of  a  320x240  pixel  matrix  of  mierobolometers  integrated 
into  an  automotive  eamera  design,  with  the  thermal  image  of  the  seene  to  be  broadeasted 
to  the  HUD  [37], 

b.  HUD  Use  in  the  Government 

The  U.S.  Intelligent  Vehiele  Highway  System  (IVHS)  Program,  was 
chartered  under  the  Inter-modal  Surfaee  Transportation  Effieiency  Aet  of  1991  to 
improve  highway  safety,  reduee  eongestion,  enhanee  mobility,  minimize  environmental 
impaet,  save  energy,  and  promote  eeonomie  produetivity  in  the  national  transportation 
system  [16].  The  IVHS  strategic  plan  was  developed  in  part  based  on  the  modeling  and 
simulation  of  the  following;  urban  traffie  networks,  vehieles,  highway  infrastrueture, 
driver  population,  traffie  models  with  dynamie  traffie  assignment,  driving  seenarios 
simulation,  and  advaneed  vehicle  eontrol  systems  (AVCS)  arehiteeture,  to  study  the 
effeets  of  HUDs  and  safety.  The  objeetives  were  to  assure  in-vehiele  information 
systems  are  safe  and  usable,  and  to  test  different  formats  and  how  they  affeet  the 
workload  of  operators  of  eommereial  vehieles.  The  studies,  eondueted  under  the  auspiees 
of  the  U.S.  Department  of  Transportation  (DOT),  produeed  results  that  have  been  applied 
by  the  developers  of  in-vehicle  information  systems  sueh  as  HUDs  used  in  eommereial 
vehicles  [16]. 

Most  of  the  military’s  development  of  teehnology  for  HUDs  has  been  for 
aireraft.  The  United  States  Air  Foree  (USAF)  Offiee  of  Seientifie  Researeh  sponsored 
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the  University  of  Idaho  to  eonduet  a  study  on  the  use  of  HUDs  and  presenting 
information  to  support  the  peripheral  vision  of  pilots  [25].  The  three-year  simulation- 
based  study,  whieh  eoneludes  in  2001,  will  provide  some  eonsensus  to  questions  about 
operator’s  pereeptual  systems,  helping  to  delineate  how  to  build  better  HUDs  for  use  in 
the  eoekpit  of  an  aireraft. 

USAF  MSgt  Fletcher  Burns’  work  on  HUDs  is  a  great  example  of  what 
the  military  is  doing  in  the  advancement  technology.  Bums,  chief  of  maintenance  for  the 
412*  Flight  Test  Squadron,  received  an  exclusive  Air  Force  license  to  develop  and 
market  a  HUD  mount  he  designed  while  working  on  a  flight  test  project  [35].  The  HUD 
mount  is  currently  being  used  on  Speckled  Trout  aircraft. 

HUDs  are  used  in  some  of  the  aircraft  operated  by  the  Test  Pilot  School  of 
the  U.S.  Air  Force.  The  Air  Force  is  convinced  that  the  use  of  HUDs  can  significantly 
enhance  flight  safety  and  has  tested  HUDs  extensively,  using  students  at  the  Test  Pilot 
School  (TPS)  as  subjects.  The  Flight  Safety  Foundation  determined  that  HUD 
technology  could  have  helped  or  positively  influenced  the  outcome  of  one-third  of  some 
1,000  civilian  jet  aircraft  crashes,  from  1959  to  1989  [32].  TPS’  objective  is  to  enhance 
the  pilot’s  situational  awareness  in  difficult  flying  conditions.  The  aircraft  that  TPS  uses 
is  the  Speckled  Trout,  which  is  the  same  aircraft  CMSgt  Burns  developed  the  HUD 
mount  for.  The  study  they  are  conducting  is  named  Project  Have  Vision,  with  goals  of 
collecting  sufficient  data  on  the  performance  of  basic  HUD  technology  and  to  seek  Air 
Force  Flight  Standards  Agency  certification  of  HUD  as  a  primary  flight  display. 
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6. 


Standards 


In  the  advent  that  HUD  use  beeomes  widespread,  government  agencies  have 
begun  to  implement  standards  and  guidelines  for  HUD  development.  The  U.S.  DOT 
released  standards  for  visual  displays  within  vehicles.  The  standards  offer  guidance  in 
the  use  of  color,  display  characteristics,  location,  and  brightness.  The  stated  reason  for 
setting  standards  for  HUDs  is  safety.  The  U.S.  DOT  wants  to  ensure  that  developers  of 
such  systems  follow  guidelines  that  are  based  on  basic  and  applied  research,  such  as  that 
conducted  by  Chrysler,  Boeing,  and  other  government  agencies. 

Guidelines  for  the  paramount  in-vehicle  display  have  been  determined  by  a 
formula  derived  by  Kimura,  Sugira,  Shinkia  and  Nagai  in  1988  [25].  These  guidelines 
were  for  setting  a  HUD’s  parameters  to  be  optimal.  The  HUD  should  have  a  large  FOV 
and  be  positioned  in  the  correct  angle  of  the  user.  The  FOV  should  be  2.0  degrees 
vertical  by  4.0  degrees  horizontal,  with  an  image  distance  of  4000mm,  lookdown  angle  of 
6.0  degrees  and  an  image  brightness  variation  of  2:1.  These  specifications  are  optimal 
but  small  variances  would  likely  be  amenable  for  the  first  iteration  of  the  use  of  AVAILS. 
All  examples  are  based  on  an  average  size  male  driver  of  5 ’9”  to  5’ 10”  and  variances 
would  certainly  play  a  factor  for  the  size  of  the  operator  of  the  vehicle  [2]. 

The  ideal  environment  for  vehicle  cabs  for  persons  between  the  5**^  and  95* 
percentile  of  operators  has  been  described  in  the  literature  [12]  The  environment  consists 
of  twenty-eight  inches  maximum  to  prime  displays,  with  the  prime  display  being  within 
the  range  of  fifteen  to  thirty  degrees  above  the  direct  horizontal  line  of  sight,  and  a  90- 
degree  angle  from  standard  line  of  sight  to  in-dash  display  [12].  These  standards  are  all 
considerations  for  the  implementation  of  AVAILS. 
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7. 


Discussion 


The  needs  and  limitations  of  users  must  be  examined  as  part  of  the  development 
of  the  HUD  to  be  used  in  AVAILS.  Some  areas  of  importanee  are: 

•  Needs  analysis 

•  Situation  of  concern 

•  What  is  currently  in  use? 

•  Goals  of  product 

•  What  is  the  desired  end  state? 

It  is  also  important  to  ensure  that  features  are  going  to  be  usable  and  user  friendly. 
In  order  to  address  usability  and  user-friendliness,  one  needs  to  consider  the  following: 

•  What  will  the  user  be  able  to  do  with  system? 

•  User  analysis 

•  User  characteristics 

•  What  skill  is  required  (computer  knowledge)? 

In  considering  the  user  needs  and  features  we  can  then  deliberate  design  support 
and  prototyping,  which  includes  such  things  as  the  following: 

•  Conceptual  design 

•  Physical  design 

•  Objects  used 

•  Where  will  it  be  located? 
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Visual  design 


•  How  big,  color  scheme? 

•  How  will  functionality  be  accessed  (e.g.,  buttons,  menu,  voice)? 

Once  there  is  a  prototype  available,  it  must  be  shown  to  potential  users.  It  also 
needs  to  be  tested  on  a  user  that  may  be  new  to  the  task  being  done  by  the  actual  user 
base;  the  reason  for  this  is  to  demonstrate  the  ease  of  use  and  understanding  of  the 
system.  If  a  person  unfamiliar  with  the  task  of  driving  in  a  convoy  or  using  electronic 
devices  to  assist  in  driving  can  use  this  tool  without  much  difficulty,  then  there  is 
evidence  that  may  be  able  to  quickly  learn  to  use  the  new  system  in  an  effective  manner. 
Extensive  user  analysis  with  AVAILS  will  be  left  to  future  research.  The  focus  of  this 
thesis  is  on  the  specification  of  requirements  for  AVAILS  and  its  HUD,  rather  than  on  a 
detailed  design.  We  use  a  software -based  prototype  of  the  HUD  to  illustrate  the 
requirements  that  we  have  developed.  The  following  is  suggested  as  future  research: 

•  Run  experiments  to  determine  what  percentage  of  the  drivers  of  military  transport 
vehicles  can  learn  to  effectively  use  AVAILS 

•  Perform  design  evaluation 

•  Perform  usability  specification 

•  Refine  AVAILS  based  on  feedback  from  operation’s  data 

•  Develop,  collect,  and  analyze  measures  of  the  system’s  effectiveness 
Other  questions  include,  but  are  not  limited  to  the  following: 

•  Can  users  use  the  system  optimally? 
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Are  all  options  easy  to  use? 


•  How  long  does  it  take  to  go  through  options? 

•  What  ean  be  done  to  help  drivers  use  the  system? 

•  Was  the  system  easy  to  use  and  understand? 

•  How  mueh  training  is  required  to  use  the  system? 

•  Will  effieieney  inerease  and  error  rate  deerease  with  training? 

•  Do  the  users  make  errors? 

•  When  they  make  an  error,  are  they  able  to  reeover? 

•  What  errors  were  made? 

Some  of  the  questions  that  should  be  addressed  during  the  detailed  design  of 
AVAILS  include  the  following; 

•  Did  we  meet  the  user  specification? 

•  What  changes  were  suggested? 

•  Would  users  actually  like  to  see  this  system  fielded? 

Consideration  must  be  taken  in  the  implementation  of  AVAILS  so  it  will  be 
beneficial  to  its  users  and  in  the  following  guidelines  set  forth,  AVAILS  will  have  a  great 
chance  of  meeting  its  goals. 

B,  ENVIRONMENTAL  CONSIDERATIONS 

Seasonal  weather  conditions  (e.g.,  fog,  snow,  sleet,  rain)  and  other  environmental 
conditions  will  shape  the  requirements  for  AVAILS.  AVAILS  will  assist  vehicle 
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operators  in  operating  their  vehiele  around  other  objeets  over  a  wide  speetrum  of 
environmental  eonditions.  The  highest  rate  of  motor  vehiele  aeeidents  oeeur  under  some 
of  the  more  extreme  weather  conditions.  AVAILS  will  only  be  concerned  with  providing 
collision  warning  or  collision  avoidance  for  the  host  vehicle  as  it  operates  near  other 
objects  under  the  most  common  environmental  conditions  in  which  military  vehicles  are 
operated,  some  of  which  could  be  severe,  but  would  likely  not  include  extreme 
environmental  conditions  such  as  hurricanes,  flash  floods,  tsunamis,  and  typhoons. 

C.  DRIVING  PROTOCOLS 

Currently,  there  is  no  standard  overall  document  dictating  specific  rules  and 
guidelines  for  driving  on  the  nation’s  highways.  The  NHTSA,  under  the  cognizance  of 
DOT,  may  provide  information  for  developing  guidelines  for  traffic  laws,  but  NTHSA’s 
primary  charter  is  to  reduce  the  frequency  and  severity  of  motor  vehicle  crashes  [29].  The 
majority  of  highway  regulations  are  derived  from  individual  state  governmental  agencies. 
This  practice  explains  why  speed  limits  and  other  basic  traffic  regulations  vary  from  state 
to  state  [46].  State  agencies  also  play  a  role  in  regulating  the  deployment  of  intelligent 
transportation  systems,  (ITS),  such  as  smart  cards,  electronic  toll  collection  and  semi- 
automated  metropolitan  transit  systems.  There  does  exist  a  certain  commonality  of  law  in 
regards  to  governing  basic  vehicle  operation.  These  rules  range  from  obeying  common 
traffic  signs  (e.g.,  stop  signs,  highway  entry  signs),  highway  information  signs  (e.g., 
construction  area,  driver  assistance  points),  and  right-of-way  privileges.  Accordingly, 
AVAILS  requirements  need  to  be  congruent  with  DoD  traffic  regulations  with  adherence 
to  the  “commonality”  of  inter-state  highway  rules  and  regulations.  The  driving  protocols 
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will  form  the  basis  of  the  eore  system  requirements  of  AVAILS.  The  following  system 
requirements  demonstrate  a  few  of  the  “eommonality”  law  interpretations: 

•  Maintain  suffieient  distance  from  lead  vehicles  when  operating  vehicles  in 
weather  conditions  that  are  known  to  make  vehicle  operation  hazardous. 

•  Complete  passing  maneuver  only  when  the  vehicle  being  passed  has  been  sighted 
in  rear  or  side  mirrors. 

These  are  just  a  few  of  the  driver  protocols  that  may  actually  become  desired  system 
requirement  in  AVAILS.  As  with  most  ITS,  driving  distance  requirements  will  have  the 
most  impact  on  system  requirements. 

D,  CONCEPTUALIZED  AVAILS-HCI 

AVAILS  has  been  generically  derived  from  examining  environmental  conditions 
and  common  driver  protocols,  and  interpreting  these  items  into  system  requirements. 
Figure  8,  depicts  the  process  used  to  conceptualize  AVAILS.  AVAILS  can  be  derived  by 
combining  DoD  motor  vehicle  operating  protocols,  common  state  and  local  highway 
regulations,  and  specific  environmental  conditions  under  which  the  system  must  continue 
to  operate.  The  requirements  for  AVAILS-HCI,  as  conceptualized  in  this  thesis  is  shown 
in  Figure  1. 
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Figure  8.  The  coneeptualization  of  the  AVAILS-HCI. 
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IV.  RELATED  WORK 


The  desire  to  develop  intelligent  transportation  systems  (ITS)  to  assist  the 
efficiency  and  safety  of  the  nation’s  highways  is  not  a  new  concept.  The  California 
Partners  for  Advanced  Transit  Highways  (PATH)  Program,  for  instance,  has  been 
conducting  ITS  research  since  its  inception  in  the  1980s  [33].  The  California  PATH  also 
maintains  a  large  database  of  literature  on  ITS  programs  and  research  conducted  by  other 
institutions  [34].  There  are  many  technological  devices  that  assist  highway  and  vehicle 
management.  There  are  electronic  toll  collections  devices,  smart  cards,  and  automated 
(i.e.,  driverless)  metropolitan  transit  systems.  Many  devices  are  now  being  added  to  the 
vehicle  itself  such  as  rear  object  detection  devices,  intelligent  navigation  and  adaptive 
cruise  control  systems.  Improvements  on  these  devices  are  always  desirable  and  research 
in  these  areas  has  gained  a  new  momentum  as  the  nation’s  highway  infrastructure 
becomes  better  suited  for  supporting  in-vehicle  applications  of  ITS. 


Safety  benefits  of  collision  avoidance  systems  has  been  a  subject  of 
considerable  experimental  and  analytical  research  which  has  established 
conceptual  descriptions  of  various  kinds  of  CAS,  CAS  designs  and  sub¬ 
system  performance  guidelines,  crash  types  targeted  by  different  CAS, 
crash  mitigation  benefits  estimates  for  different  CAS  concepts],  and  design 
and  specification  guidelines  for  CAS  human-machine  interfaces.  The 
research  has  aimed  to  characterize  the  performance  of  prototype  systems 
the  operating  environment  of  CAS  sensor  subsystems,  driver  behavior 
under  normal  driving  conditions,  and  driver  interaction  with  partially 
automated  vehicles.  Although  a  great  deal  progress  has  been  made  in 
these  areas,  much  work  is  still  required  to  better  understand  the 
relationships  between  benefits,  user  acceptance,  CAS  subsystem 
requirements,  driver  behavior  and  the  driving  environment... 


Due  to  recent  advances  in  technology,  it  is  possible  to  detect,  using  software- 
controlled  sensors,  many  types  of  stationary  and  moving  objects  in  the  path  of  a  vehicle. 
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These  obstacle-detection  systems  can  warn  the  driver  of  an  impending  collision  and 
initiate  preventive  actions,  on  the  vehicle  itself,  to  avoid  the  collision.  A  few  systems  to 
note  are  the  Eaton  Vehicle  Onboard  RADar  (VORAD),  Maneuvering  Aids  for  Low 
Speed  Operation  (MALSO),  and  Automotive  Collision  Avoidance  System  (ACAS). 
VORAD  is  one  of  the  systems  that  closely  resemble  AVAILS.  MALSO  employs  similar 
object  detection  methodologies  into  its’  design.  ACAS  is  a  development  concept 
sponsored  by  NHTSA  [30]  in  an  attempt  to  explore  and  develop  collision  avoidance 
systems  that  will  assist  drivers  in  safely  executing  lane  changes,  merging,  and  backing 
maneuvers.  These  are  just  a  few  of  the  systems  under  development  that  either  serve  as 
CWS,  CAS,  or  a  combination  of  both.  Due  to  the  varying  degrees  of  expertise,  variety  of 
new  ideas,  application  experimentation  and  results  analysis,  there  has  never  been  a 
predefined  guideline  or  set  of  protocols  for  developing  automated  vehicle  software 
systems  or  ITS  [4].  The  Hierarchical  Assessment  and  Requirement  Tools  for  Crash 
Avoidance  System  (HARTCAS)  is  a  development  tool  that  proposes  a  five-layered 
hierarchical  modeling  framework  for  CAS  benefit  assessment  and  requirements 
development  [4].  The  HARTCAS  framework  is  intended  to  reduce  the  complexity  of  the 
analysis  of  a  proposed  system,  which  would  allow  the  study  of  system  parameters  over  a 
range  of  values,  driving  scenarios,  environmental  conditions,  and  system  capabilities.  In 
this  thesis  we  focus  on  the  specification  of  the  requirements  for  the  driver  interface  of 
AVAILS.  The  requirement  specification  is  a  prerequisite  for  using  the  HARTCAS 
modeling  hierarchy  shown  in  Ligure  9. 
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Figure  9.  HARTCAS  Modeling  Hierarehy  (From;  [4]) 


All  of  the  previously  mentioned  systems  serve  a  CWS  with  only  AC  AS  venturing 
into  the  realm  of  CAS.  Eaeh  system  will  be  examined  briefly  in  subsequent  seetions. 
The  point  of  emphasis  should  be  direeted  at  the  faet  eaeh  of  the  systems  are  inherently 
designed  as  a  CWS  or  CAS.  The  two  terms  are,  although  eoneeptually  similar,  are 
distinetly  different  in  their  roles  they  share  in  autonomous  systems.  CWS  and  CAS  will 
be  examined  separately. 
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A.  COLLISION  WARNING  SYSTEMS  (CWS) 

Collision  warning  systems  warn  the  driver  to  impending  eollisions  either  through 
physieal,  audible,  or  visual  means.  The  CWS  warnings  ean  be  given  in  a  variety  of  ways. 
Physieal  warnings  can  be  through  haptic  feedback,  such  as  vibrating  the  steering  wheel  or 
the  driver’s  seat.  Audible  warnings  can  be  provided  by  a  variety  of  messages,  beeps,  or 
sounds.  Visual  warnings  can  be  given  by  flashing  lights  or  indicators.  As  a  CWS,  no 
direct  action  is  taken  to  take  active  control  of  the  vehicle  and  initiate  preventive  measures 
for  avoiding  collisions.  The  CWS  only  alerts  the  driver  of  an  impending  collision.  Once 
alerted,  the  driver  can  employ  evasive  actions  to  avoid  a  collision.  AVAILS  is  primarily 
a  CWS.  The  system  interface  is  designed  to  provide  the  driver  audible  warnings  when  a 
collision  with  another  vehicle  or  a  docking  platform  is  impending.  The  system  is  not 
intended  to  warn  the  driver  of  the  presence  of  pedestrians. 

B,  COLLISION  AVOIDANCE  SYSTEMS  (CAS) 

CAS,  unlike  CWS,  seeks  to  initiate  some  action  on  the  vehicle.  The  most 
common  form  of  CAS  can  be  seen  in  adaptive  cruise  control  (ACC).  Current  adaptive 
cruise  control  technologies  employ  both  radar  and  LIDAR  (light  detecting  and  ranging) 
[9].  Using  object  detection,  the  system  adjusts  the  speed  of  the  vehicle  in  an  attempt  to 
maintain  a  safe  following  distance  from  the  lead  vehicle.  The  driver  must  turn  on  the 
ACC  and  retake  control  of  the  vehicle  once  the  ACC  is  turned  off  or  deactivates  itself 
because  the  minimum  safe-following  distance  was  violated.  Other  forms  of  CAS  are 
limited  braking,  throttle  integration/resistance,  or  forward-looking  sensors.  The  role  of 
CAS  in  AVAILS  is  very  limited.  The  only  CAS  functionality  considered  for  inclusion  in 
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AVAILS  is  adaptive  cruise  control.  This  functionality  can  be  borrowed,  to  some  extent, 
from  existing  commercial  products. 

C.  EXISTING  SYSTEMS 

As  previously  mentioned,  VORAD,  MALSO,  and  ACAS  are  all  systems  that 
serve  the  role  of  a  CWS.  Only  ACAS,  as  a  developmental  concept  inspired  by  NHTSA, 
explores  CAS  in  automotive  systems.  AVAILS  echoes  the  same  intent  as  each  of  these 
systems. 

1.  VORAD 

VORAD  is  a  CWS  designed,  specifically  for  large  trucks,  by  the  Eaton 
Corporation  as  part  of  its  intelligent  truck  components  for  fuel  economy  and  safety 
business.  Eaton  claims  that  the  usage  of  CWS  can  reduce  total  accident  costs  by  thirty- 
three  percent  [26].  An  Iowa  State  University  study  concluded  that  the  majority  of 
forward  and  side  collisions  account  for  approximately  ninety-four  percent  of  all  accident 
costs  involving  large  trucks.  VORAD  uses  radar  as  its  principle  means  of  object 
detection.  The  radar  is  federally  approved,  does  not  pose  any  danger  to  other  motorists, 
nor  does  it  affect  law  enforcement  radar  usage  or  any  other  radar  devices  in  other 
vehicles.  VORAD  consists  of  three  major  components:  the  antenna  transceiver  assembly, 
the  central  processing  unit,  and  the  driver  display  unit.  The  AVAIES-HCI  more  closely 
resembles  VORAD  than  any  of  the  other  systems.  The  placements  of  the  three  major 
devices  in  VORAD  are  depicted  in  Eigure  10. 
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Figure  10.  Eaton  VORAD  (From;  [26]) 


In  addition  to  the  three  major  components,  there  are  sensors  mounted  on  either  side  of  the 
cab.  These  sensors  can  detect  objects  anywhere  from  two  to  ten  feet  near  the  truck. 
Vorad  equips  the  truck  with  one  sensor  that  is  mounted  on  the  passenger  side  of  the  truck. 
The  driver  has  a  full  range  of  view  on  the  driver’s  side.  However,  a  second  sensor 
mounted  on  the  driver’s  side  is  optional.  The  antenna  beam  coverage  for  VORAD  will 
spans  a  height  of  five  degrees  and  a  width  of  twelve  degrees,  allowing  Vorad  to  detect 
most  objects  in  its  immediate  path,  as  shown  in  Figure  IF  If  the  driver  were  maneuver 
around  a  curve,  the  gyroscope  housed  in  the  central  processing  unit  shapes  the  radar 
detection  zone  to  the  curvature  of  the  roadway.  This  would  effectively  keep  the  radar 
coverage  on  the  road  rather  than  perpendicular  to  the  road. 
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Figure  11.  Antenna  Beam  Coverage  (From;  [26]) 


Figure  12.  Driver  Display  Unit  (From;  [26]) 


The  driver  display  unit  has  a  rather  simple  design,  as  shown  by  Figure  12.  The  driver 
display  unit  provides  audible  warning  alerts  to  the  driver.  There  is  a  slot  for  the  driver’s 
identifieation  eard.  Depressing  the  range  knob  in  or  out,  allows  the  driver  to  manipulate 
various  funetions  of  the  system.  The  various  warning-level  lights  (ovals  in  the  eenter  of 
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Figure  12,  from  left  to  right),  inerease  in  eritieality.  The  warning  lights  ehange  in  eolor, 
from  yellow  to  a  reddish  tint.  VORAD  offers  adaptive  eruise  eontrol  and  a  host  of  other 
options  as  optional  functionality. 

2.  Maneuvering  Aids  for  Low  Speed  Operation  (MALSO) 

MALSO  are  detection  devices  with  non-contact  sensors  that  are  intended  for  use 
on  light-duty  vehicles  to  assist  the  driver  during  low-speed  maneuvering.  MALSO 
systems  indicate  to  the  driver  the  presence  of  front,  rear,  or  comer  objects  when 
maneuvering  into  small  parking  spaces  or  negotiating  narrow  passages.  They  are 
regarded  as  an  aid  to  drivers  for  use  at  speeds  of  up  to  one  meter-per-second,  but  they  do 
not  relieve  the  driver  of  the  driving  task.  MALSO  systems  use  object-detection  devices 
for  ranging  in  order  to  provide  the  driver  with  information  based  on  distance  to  obstacles. 
It  specifies  minimum  functionality  requirements  that  the  driver  can  generally  expect  of 
the  device,  that  is,  detection  and  identification  of  obstacles  within  a  defined  detection 
range.  It  defines  minimum  requirements  for  failure  indication  as  well  as  performance  test 
procedures,  and  it  includes  mles  for  the  general  information  strategy,  but  does  not  place 
restrictions  on  the  kind  of  information  or  display  system  that  can  be  used. 

The  sensing  technology  is  not  addressed.  However,  technology  affects  the 
performance  test  procedures  set  up  in  this  standard.  The  current  test  objects  were  defined 
based  on  systems  using  ultrasonic  sensors,  which  is  the  most  commonly  used  technology 
at  the  time  of  editing  this  standard.  For  future  sensing  technologies,  these  test  objects 
shall  be  checked  and  changed  if  required.  MALSO  is  depicted  in  Figure  13. 
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Figure  13.  Possible  Cover  Ranges  for  MALSO  (From;  [8]) 


MALSO  are  categorized  according  to  their  capability  of  covering  different  monitoring 
areas  of  the  vehicle.  Each  monitoring  area  corresponds  to  a  particular  part  of  the  host 
vehicle  and  is  expected  to  prevent  the  vehicle  from  colliding  with  an  object.  Table  1,  lists 
the  abbreviations  for  each  monitoring  area.  Table  1  directly  corresponds  to  Figure  13. 


Monitoring  Runge 

Abbreviation 

Rear  short 

Rs 

Rear  basic 

Rb 

Rear  extended 

Re 

Rear  corner  driver  side 

Red 

Rear  corner  passenger  side 

Rep 

Front 

F 

Front  comer  driver  side 

Fed 

Front  comer  passenger  side 

Fep 

Front  side  dnver  side 

Fsd 

Front  side  passenger  side 

Fsp 

Table  1.  MALSO  Monitoring  Ranges  (From;  [8]) 
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MALSO  can  be  activated  or  deactivated  by  a  switch  or  push  button.  When 


activated,  the  system  indicates  readiness  either  acoustically  or  visually.  The  driver’s 
interface  contains  an  audible  information  channel.  Visual  information  and  warning 
information  are  considered  to  be  additional  means  of  relaying  information  to  the  driver. 
The  most  valuable  information  to  the  driver  is  the  distance  information  of  objects  near  the 
vehicle.  MALSO  contains  only  a  bit  more  functionality  than  the  information  required  for 
AVAILS.  However,  the  concept  of  CWS  and  CAS  are  present. 

3,  Automotive  Collision  Avoidance  Systems  (ACAS)  Development 

AC  AS  is  entirely  supported  by  NHTSA,  which  is  under  the  direction  of  the  U.S. 

DOT. 


As  a  developmental  concept,  the  main  objective  the  main  objective  of  the 
program  was  to  provide  a  focused  approach  to  accelerate  the  commercial 
availability  of  a  portfolio  of  promising  key  fundamental  collision  warning 
countermeasure  technologies  and  or  systems.  As  a  result,  the  void 
between  research  and  development  and  the  actual  deployment  of  the  new 
technology,  in  the  real  world,  was  substantially  bridged.  ACAS  was 
accomplished  through  a  cooperative  arrangement  between  the  U.S. 
Government  and  a  ACAS  consortium,  whose  membership  is  comprised  of 
both  industry  and  academic  participants.  Financial  support  for  the  ACAS 
program  was  provided  by,  both  the  United  States  government  and 
consortium  members.  The  government  financially  sponsored  ACAS 
through  the  Defense  Advanced  Research  Project  Agency  (DARPA),  in 
accordance  with  the  guidelines  of  the  Technology  Reinvestment  Program 
(TRP).  The  Additionally,  the  government  actively  participated  in  the  ACAS 
Program  activities,  through  NHTSA,  which  administered  the  ACAS 
Program  on  behalf  of  government  [39] . 


Furthermore; 


The  ACAS  Program  has  laid  a  solid  foundation  towards  the 
implementation  of  a  comprehensive  collision  warning  system,  which  is 
capable  of  detecting  and  warning  the  driver  of potential  hazard  conditions 
in  the  forward,  side,  and  rear  regions  of  the  vehicle.  Performance 
requirements  of  the  major  components  of  the  CW  system,  such  as  long 
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range  forward-looking  detection  sensors  (radar  or  optical,  short  range 
side  and  rear  detection  sensors,  and  a  lane  detection  vision-based  were 
investigated.  Finally,  the  effectiveness  of  a  variety  of  warning  cues  was 
also  studied.  The  results  of  this  program  have  generated  new  insights  for 
how  the  CW  system  should  be  configured  and  deployed  [31] . 


AC  AS  produced  substantial  gains  in  knowledge  of  CWS/CAS.  However,  there  is  a  vast 
amount  of  researeh  yet  to  be  conducted.  The  real-world  traffic  environment  is  extremely 
diverse  and  presents  an  almost  insurmountable  obstacle  for  making  sueh  systems 
relatively  free  of  false  alarms  and  missed  detections.  New  systems  could  take  advantage 
of  new  sensor  technologies  in  order  to  inerease  potential  CWS/CAS  robustness.  We 
believe  that  ACAS  ean  assist  the  development  and  maturation  of  systems  such  as 
AVAILS. 
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V.  AVAILS-HCI  SOFTWARE  DESIGN  SPECIFICATION 


A,  SYSTEM  INTRODUCTION 


As  previously  mentioned,  the  purpose  of  this  doeument  is  to  provide  an 
introduction  into  the  AVAILS-HCI.  AVAILS,  as  an  entire  system,  will  not  be  described 
in  this  document.  Only  the  requirements  for  the  AVAILS-Human  Computer  Interface 
(HCI)  will  be  described  in  detail.  The  HCI  display  on  the  main  console  is  of  particular 
importance  and  will  be  discussed  in  detail  since  it  is  the  main  focus  of  this  research.  The 
main  console  is  depicted  in  Figure  14.  The  HCI  consists  of  the  display  of  the  main  menu 
and  sub-menu  options.  The  sub-menus  are  the  mode  menu  options,  the  settings  menu 
option,  and  weather  settings  menu. 


f - \ 

WEATHER 

SETTINGS 

V _ / 

/ - \ 

RESET 


V _ 


MESSAGE  BOX 


Figure  14.  THE  AVAILS-HCI 


53 


B, 


SYSTEM  OVERVIEW 


The  main  console  is  designed  with  the  intent  of  providing  the  user  with  a  readily 
accessible  and  user-friendly  display  where  each  button  on  the  display  provides  an 
intuitive  meaning.  The  labeling  of  each  menu  option  was  done  in  a  manner  as  to  imply 
its  direct  meaning. 

Figure  15,  depicts  the  basic  process  associated  with  operating  the  AVAILS-HCI. 


Figure  15.  AVAILS-HCI  Flowchart 


AVAILS  is  activated  by  pressing  the  ON/OFF  button.  Upon  being  activated,  the  user  is 
presented  with  the  first  sub-menu.  The  user  must  select  either  the  “Park”  mode  or  the 
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“Travel”  mode.  If  the  park  mode  is  seleeted,  all  sensors  located  alongside  the  truck  will 
automatically  be  set  for  near-object  detection;  that  is,  all  the  sensors  will  be  preset  to 
detect  nearby  stationary  objects.  Park  mode  allows  the  driver  to  maneuver  and  park  their 
trailers  within  inches  of  other  objects.  This  mode  is  designed  with  pre-embarkation 
operations  where  equipment  is  staged  in  lots  for  loading  on  shipping  or  aircraft. 

The  travel  mode  is  expected  to  be  the  most  utilized  of  the  system.  As  its  name 
implies,  travel  mode  is  used  when  a  vehicle  is  being  driven.  By  selecting  the  travel 
mode,  the  user  is  then  presented  with  the  “Settings”  menu  option.  The  two  options 
available  here  are  the  “User”  and  “Default”.  The  default  settings  initialize  preset  vehicle 
distances  for  all  pre-programmed  environmental  conditions.  The  “User”  option  allows 
the  user  to  input  his  or  her  trailing  or  passing  distance. 

The  user  is  then  presented  with  the  “Weather  Settings”  menu.  The  menu  allows 
the  user  to  select  their  current  driving  condition  (e.g.,  rain,  fog,  snow).  The  user  must 
select  a  weather  condition  before  preceding  any  further.  Under  the  “User”  mode,  the 
user  is  presented  with  the  window  to  enter  the  desired  trailing  or  passing  distance. 
Lateral  separation  is  only  a  factor  in  low-speed  docking  maneuvers.  The  “Reset”  process 
is  used  when  the  user  needs  to  start  the  process  all  over  again,  or  clear  previous  entries. 

The  user  can  either  set  the  system  while  the  vehicle  is  at  rest  or  in  motion.  If  the 
vehicle  is  in  motion,  it  is  probably  best  to  present  the  user  with  a  HUD.  The  user  must 
input  a  selection  for  every  menu  that  is  presented.  If  a  selection  is  not  made,  the  user  will 
continually  be  presented  with  that  particular  menu  until  either  the  system  is  turned  off  or 
the  reset  button  is  used.  The  minimum  distance  for  any  menu  option,  involving  distance, 
in  the  travel  mode  is  computed  based  on  the  acceleration  and  other  performance 
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characteristics  of  the  vehiele.  For  example,  the  braking  distanee  at  maximum  deeeleration 
for  a  five-ton  long  truek  (see  Figure  3)  is  different  from  that  of  a  traetor-trailer  that  is 
hauling  a  fully  loaded  fuel  earrier  (see  Figure  4).  The  eomputations  are  based  on  a  range 
of  speeds  up  to  the  maximum  allowable  speed  limit  within  the  U.S.,  whieh  is  seventy-five 
miles-per-hour  [46].  Speed  limits  in  other  eountries  are  of  little  coneern  simply  beeause 
military  eonvoys  operating  in  other  eountries  would  never  approaeh  sueh  unsafe  speeds, 
espeeially  if  bulk  eargo  is  being  carried. 

1.  User  Option  and  First-Level  Menus 


Figure  16,  depiets  the  relationships  between  the  options  and  menus  shown  on  the 
AVAILS-HCI  main  eonsole  (see  Figure  14). 


Figure  16.  First-Level  Menus  and  Options 
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Item 

Name 

Function 

1.0 

MAIN 

CONSOLE 

The  entire  user  interface  pictured  in  Figures  1,  &  14. 

2.0 

SUB-MENUS 

The  first-level  menu  options. 

2.1 

MODE 

The  first  menu  presented  to  the  user  allowing  them  to  choose  between 

“Park”  and  “Travel”  modes. 

2.2 

SETTINGS 

The  second  menu  presented  to  the  user  allowing  them  to  choose  between 

“User”  and  “Default”  mode. 

2.3 

WEATHER 

The  third  menu  option  presented  to  the  user  allowing  them  to  choose 

SETTINGS 

between  various  weather  conditions. 

3.0 

OPTIONS 

Represents  all  basic  function  items. 

3.1 

ON  /  OFF 

Activates  and  de-activates  the  AVAILS  console. 

3.2 

RESET 

Clears  all  previous  system  settings. 

4.0 

INDICATORS 

Represents  all  warning  devices. 

4.1 

CLEAR 

Flashes  green  and  is  accompanied  with  a  beep  when  it  is  clear  to  pass. 

4.2 

NOT  CLEAR 

Flashes  red  and  is  accompanied  with  a  beep  when  it  is  not  clear  to  pass. 

4.3 

MESSAGES 

A  text  box  that  shows  various  messages. 

4.4 

CLEARANCES 

A  text  box  that  shows  the  current  distance  to  vehicles  being  passed. 

Table  2.  AVAILS  Function  Chart. 


Table  2,  provides  a  brief  description  of  each  numbered  options  shown  in  Figure  16. 
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Figure  17.  2“‘*  and  3'^'*  Level  Menus. 


Figure  17  presents  the  remaining  menu  options;  their  meaning  is  implicit  and  do 
not  require  further  explanation.  Menu  item  (2.3.1.)  shows  all  of  the  available  weather 
conditions.  Menu  item  (2.1.1)  represents  the  two  modes  of  AVAILS.  As  previously 
mentioned,  parking  mode  automatically  sets  the  sensor  nodes  to  detect  nearby  stationary 
objects  whereas  traveling  mode  opens  the  sensors  to  further  ranges.  Menu  item  (2.2.1) 
shows  the  default  setting,  which  automatically  sets  a  distance  for  each  weather  condition. 
The  user  option  allows  the  driver  to  enter  their  own  distance  for  their  driving  condition. 
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2,  System  Messages 


The  message  box  loeated  at  the  bottom  of  the  AVAILS-HCI  will  only  display  a 
limited  amount  of  messages.  The  only  audible  warnings  provided  to  the  driver  are  a 
series  of  beeps.  There  will  not  be  any  voiee  messages  within  the  system.  The  general 
messages  are  shown  in  Table  3. 


Number 

Message 

1 

WARNING! 

2 

USER  PASSING  DISTANCE  SET  AT  =>  n 

3 

DEFAULT  PASSING  DISTANCE  SET  AT  =>  n 

4 

PRESS  RESET  FOR  NEW  ENTRIES  OR  TO  START  OVER 

5 

DO  NOT  PASS! 

6 

COMPLETE  PASS! 

7 

MAKE  A  SELECTION  OR  HIT  RESET  TO  START  OVER 

Tables.  AVAILS-HCI  Messages. 


The  “n”  shown  in  message  numbers  two  and  three  represents  either  the  default 
distanee  or  the  user-entered  distanee.  The  distanee  is  an  integer  value  selected  by  the 
user.  If  the  user  chooses  to  use  the  default  system  settings,  the  distance  is  chosen  for 
them  based  upon  the  weather  condition  chosen  by  the  user. 
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3. 


The  Main  Display 


Figure  18,  shows  the  main  display,  which  is  located  in  the  center  of  the  AVAILS- 
HCl  console. 


AVAILS 

a 

Figure  18.  AVAILS  Main  Display. 


The  main  display  depicts  the  vehicle  in  the  center  of  the  map.  A  distance  of  one 
lane  is  represented  on  each  side  of  the  vehicle.  Each  side-mounted  sensor  node  will 
cover  a  range  equal  to  the  distance  of  one  lane.  As  the  driver  passes  an  object  (a  vehicle), 
that  object  will  be  shown  on  the  display.  When  the  object  reaches  the  preset  distance,  the 
system  will  let  the  driver  know  if  it  is  ok  to  complete  the  pass  or  not.  The  map  is  not  to 
scale  so  the  driver  must  look  at  the  distances.  The  driver  can  view  the  distances  of  lead 
and  rear  objects  by  viewing  the  clearance  text  boxes  on  the  main  console,  as  shown  in 
Figure  19.  Side  distances  are  not  provided  since  the  driver  must  execute  a  pass  in  a 
separate  lane. 
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Figure  19.  Front  and  Rear  Clearances. 

The  distances  detected  from  the  sensors  will  be  displayed  in  the  text  boxes.  If  the 
situation  arises  where  more  than  one  vehicle  is  being  passed  (a  vehicle  on  the  right  and 
left),  then  each  detected  object  would  have  to  be  uniquely  identified.  Multiple  object 
detection  and  processing  are  ideal  topics  for  future  research. 

C.  DESIGN  CONSIDERATIONS 

AVAILS  represents  a  software  application  that  consists  of  three  hardware 
components,  the  main  console  and  the  sensor  nodes  and  their  interconnecting 
transmission  media.  Memory  requirements,  as  well  as  a  capable  operating  system,  must 
be  sufficient  in  order  to  perform  data  sensor  fusion. 

1,  Assumptions  and  Dependencies 

There  are  a  few  assumptions  made  concerning  the  driver,  the  presumed  user  of 
AVAILS.  We  assume  that  the  driver  has,  at  the  very  least,  a  high  school  education  and 
has  limited  exposure  to  in-vehicle  computer  applications.  We  also  assume  that  the  host 
vehicle  will  power  AVAILS.  We  also  assume  that  existing  military  motor  pool  personnel 
and  contractors  can  instrument  the  vehicles  with  the  AVAILS  system. 
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2. 


General  Constraints 


We  designed  the  prototype  of  the  AVAILS-HCI  in  the  Java  programming 
language.  The  main  eonsole  ean  only  funetion  inside  the  operator  eompartment  with  an 
ample  power  supply.  AVAILS  was  not  designed  to  run  absent  a  host  vehiele.  AVAILS 
is  not  eurrently  interoperable  with  any  other  software  applieations. 

3,  Goals  and  Guidelines 

The  main  goal  of  this  thesis  was  to  produee  a  generic  HCI  and  demonstrate  the 
functionality  of  the  main  display  and  sub-menus  options.  The  desired  outcome  is  to  have 
a  functioning  user  interface  that  is  simple,  efficient,  and  one  that  promotes  usability. 

4,  Development  Methods 

A  typical  software  design  approach  was  utilized  to  develop  the  AVAILS-HCI. 
That  is  to  say  that  AVAILS  was  first  conceptualized  and  modularized.  Then  system 
requirements  were  generated  and  subsequently  coded.  JAVA  was  chosen  as  the  core 
programming  language  due  to  its  simplicity,  portability,  and  enhanced  GUI  capability. 
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VI.  CONCLUSION 


A,  SUMMARY 

The  high-level  requirements  for  AVAILS  are  as  follows: 

•  Assist  the  driver  to  avoid  erashes  with  other  vehieles  under  nominal  and  adverse 
environmental  eonditions 

•  Provide  for  multiple  operation  modes,  eaeh  of  which  corresponds  to  the  current 
combination  of  the  following:  configuration  of  the  vehicle,  environmental 
conditions,  and  type  of  maneuver  (e.g.,  lane  change)  or  driving  activity  (i.e.,  low- 
speed  docking  versus  convoy  operation) 

The  high-level  requirements  for  the  AVAILS-HCI  are  as  follows: 

•  Be  designed  to  the  needs  of  military  personnel  who  operate  military  vehicles,  all 
of  which  have  the  following  characteristics:  typical  age  of  between  nineteen  and 
twenty-six,  hold  at  a  minimum  a  high-school  diploma  or  equivalent,  and  receive 
training  for  operating  military  vehicles 

•  Permit  the  user  of  the  HCI  to  input  information  about  the  configuration  of  the 
vehicle,  environmental  conditions,  and  type  of  maneuver  or  driving  activity 

•  Provide  for  displaying  collision-warning  information  and  limited  control  actions 
(e.g.,  engine-braking  with  haptic  feedback  to  the  pedal  that  controls  the  throttle) 
without  distracting  the  drivers  attention  from  critical  driving  tasks 
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In  this  thesis  we  explored  some  of  the  ways  in  whieh  a  heads-up  display  (HUD)  eould  be 
used  to  address  the  foregoing  high-level  requirements.  We  also  eompared  the  high-level 
requirements  for  AVAILS  with  the  funetionality  provided  by  eommereially  available 
collision  warning  and  collision  avoidance  systems.  Lastly,  we  used  the  prototype  of  the 
AVAILS-HCI,  implemented  in  the  Java  programming  language,  to  explore  some  of  the 
high-level  design  requirements  for  the  AVAILS-HCI. 

B,  FUTURE  WORK 

There  are  many  possible  avenues  for  future  research.  In  order  to  refine  the  high- 
level  requirements  for  the  HCI  into  detailed  design  specifications,  the  next  step  in  the 
research  should  consist  of  an  assessment  of  the  human-performance  requirements, 
followed  by  a  task  description  and  analysis. 

The  prototype  of  the  AVAILS-HCI  can  be  refined  to  correspond  to  the  design 
specifications,  and  then  integrated  into  a  driving  simulator  for  use  in  assessing  design 
alternatives  through  experimentation.  Such  experiments,  although  they  are  conducted  in 
a  virtual  environment  with  human  subjects,  could  be  used  to  obtain  rough  approximations 
of  the  effectiveness  of  the  AVAILS-HCI  in  terms  of  safety,  usability,  and  other  measures 
of  the  effectiveness  of  the  system.  Much  work  remains  to  be  done  to  determine  what 
types  of  warnings  should  be  provided  to  the  driver  and  how  these  warnings  should  be 
presented  (e.g.,  audible  versus  visual-based).  Issues  associated  with  missed  false  alarms 
and  nuisance  alarms  need  to  be  addressed  in  the  context  of  the  effectiveness  of  the  system 
at  preventing  crashes. 

The  focus  in  this  thesis  is  on  the  human-computer  interface.  However,  now  that 
some  of  the  high-level  requirements  for  AVAILS  and  its  HCI  are  known,  research  needs 
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to  be  conducted  to  determine  the  technical  feasibility  of  supporting  such  requirements. 
For  example,  can  present-day  sensor  (e.g.,  radar)  technology  or  data-sensor-fusion 
algorithms  support  the  requirements  for  AVAILS?  The  general  rule  in  the  US 
Department  of  Defense  is  that  new  systems  should  be  implemented  using  commercial- 
off-the-shelf  (COTS)  components,  or  reusable  components  from  legacy  systems, 
whenever  possible.  Do  the  requirements  for  AVAILS  require  the  development  of  new 
technology,  or  is  it  possible  to  reuse  existing  technology  to  meet  the  requirements? 

As  other  types  of  intelligent  transportation  systems  are  introduced  into  military 
ground  transportation  vehicles,  how  will  their  introduction  affect  the  requirements  or 
redesign  of  AVAILS  and  its  human-computer  interface?  For  instance,  will  an  onboard 
interactive  navigation  system  distract  the  driver  from  paying  attention  to  the  information 
displayed  by  the  AVAILS-HCI? 

The  requirements  for  AVAILS,  as  articulated  in  this  thesis,  are  based  on 
transportation  laws,  traffic  regulations,  and  military  doctrine,  policy,  and  procedures. 
How  might  it  be  necessary  to  make  changes  to  existing  laws,  regulations,  doctrine, 
policy,  and  procedures  in  order  to  take  full  advantage  of  the  functionality  of  AVAILS  in 
mitigating  the  risk  associated  with  crashes?  In  addition,  what  types  of  standards  or 
guidelines  would  need  to  be  put  in  place  to  ensure  that  the  components  comprising 
AVAILS,  likely  to  be  manufactured  by  more  than  one  source,  would  be  interoperable  and 
meet  minimum  requirements  for  reliability  and  safety? 

From  the  perspective  of  safety,  there  are  many  issues  to  be  addressed.  For 
example,  should  the  driver  be  permitted  to  directly  enter  values  for  the  various  system 
parameters  (e.g.,  current  environmental  conditions),  should  the  system  determine  those 
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settings  itself,  or  should  the  system  parameters  be  set  via  some  combination  of  the 
preceding  alternatives?  If  the  user  is  kept  in  the  loop  for  inputting  data  into  the  system, 
how  might  a  safety-interlock  be  used  to  prevent  users  from  initiating  a  mode  in  the 
system  is  not  capable  of  functioning  in  a  particular  point  in  time?  For  example,  when 
some  of  the  sensors  are  not  available  due  to  the  configuration  of  the  vehicle  or  the 
malfunction  of  a  sensor. 

Although  AVAILS,  as  it  is  described  in  this  thesis,  is  in  essence  autonomous,  it 
could  be  used  as  part  of  a  cooperative  system  in  which  the  data  collected  by  AVAILS  on 
one  vehicle  could  be  made  available  to  upstream  vehicles.  For  example,  downstream 
vehicles  could  provide  preview  information  to  upstream  vehicles  about  traffic  conditions 
(e.g.,  the  following  distance  and  speed  of  vehicles,  as  a  surrogate  measure  of  traffic 
congestion)  or  other  safety-related  information  (e.g.,  condition  of  the  pavement,  such  as 
dry  or  wet). 
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APPENDIX  A:  AVAILS-HCI  MODULES  (CODE) 


The  following  code  represents  the  generic  implementation  of  the  AVAILS-HCI. 
Essentially,  only  the  menus  and  sub-menus  were  activated.  The  sensor  modules, 
involving  the  processing  and  translation  of  radar  and  sensor  data  were  not  implemented 
as  they  were  beyond  the  scope  of  this  thesis,  which  was  to  conceptualize  the  AVAILS- 
HCI.  This  implementation  was  used  to  construct  the  sub  menu  options  and  test  the 
usability  (e.g.,  look,  feel,  color)  of  the  console  for  the  user.  Further  code  refinement  and 
implementation  are  left  for  future  work. 

1 .  The  MainDisplay  file  represents  the  main  display  on  the  AVAILS-HCI: 


*  File:  MainDisplay  .java 

*  Harold  M  Mosley 

*  AVAIFS  Code  -  AVAIFS-  HCI 

*  Thesis  Appendix 

*  September  20,  2001 

*  This  file  represents  the  main  console  display.  The  file  is  only  intended  to 

*  test  the  look,  feel,  and  usability  of  the  AVAIFS-HCI.  There  are  no  validity 

*  check  routines  or  sensor  modules  to  simulate  the  input  of  radar  data.  This  file 

*  only  represents  the  conceptual  phase  for  the  AVAIFS-HCI. 

V 

import  java. io.*; 
importjava.net.*; 
import  java. awt.*; 
import  j  ava.  awt.  event.  * ; 
import  j  avax . swing .  * ; 

public  class  MainDisplay  extends  JFrame  { 

//All  necessary  panel  and  buttons  are  created  here 
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private  JPanel  centerPanel,  northPanel,  southPanel,  eastPanel,  westPanel; 
private  JButton  modeButton,  settingsButton,  elearanceButton, 
weathers etButton,  resetButton,  onOffButton, 
logoButton,  elearButton,  textButton,  notClearButton, 
eenterButton; 

//variables  are  deelared  here 
private  Color  pb,  np,  ep; 
private  JTextField  messageDisplay; 
private  JLabel  label2,  textLabel; 
private  boolean  wasModeSeleetedFirst; 
boolean  modeMenuVisible; 
boolean  settingsSubMenuVisible; 
boolean  modeSubMenuVisible; 
boolean  weatherSettingsVisible; 

//eonstruetor 
publie  MainDisplayO 
{ 

super(  "AVAILS  Main  Display"  ); 

Container  e  =  getContentPane(); 

//ereate  instanees  of  panels 
southPanel  =  new  JPanel(); 
eenterPanel  =  new  JPanel(); 
northPanel  =  new  JPanel(); 
eastPanel  =  new  JPanel(); 
westPanel  =  new  JPanel(); 

//buttons  in  the  west  panel 
modeButton  =  new  JButton(  "MODE"  ); 
settingsButton  =  new  JButton(  "SETTINGS"  ); 
elearaneeButton  =  new  JButton(  "Eront/Rear  Clearanee"  ); 
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//buttons  on  the  east  panel 

weatherSetButton  =  new  JButton(  "WEATHER  SETTINGS"  ); 
resetButton  =  new  JButton(  "RESET"  ); 
onOffButton  =  new  JButton(  "ON  /  OEE"  ); 

//buttons  on  the  south  panel 

Icon  clear  =  new  ImageIcon(  "clear.gif '  ); 

clearButton  =  new  JButton(  clear  ); 

clearButton.setHorizontalAlignment(  SwingConstants. CENTER  ); 

Icon  notClear  =  new  ImageIcon(  "notClear.gif'  ); 
notClearButton  =  new  JButton(  notClear  ); 

notClearButton.setHorizontalAlignment(  SwingConstants. CENTER  ); 

//west  panel  construction 
westPanel.setEayout(  new  GridEayout(  3,1  )); 
westPanel.add(  modeButton); 
westPanel.add(  settingsButton  ); 
westPanel.add(  clearanceButton  ); 
c.add(  westPanel,  BorderEayout.WEST  ); 

//west  panel  button  handlers 

modcButtonHandler  modcHandler  =  new  modeButtonHandler(); 
modeButton.addActionListener(  modcHandler  ); 
settingsButtonHandler  settingsHandler  =  new  settingsButtonHandler(); 
settingsButton.addActionEistener(  settingsHandler  ); 

clearanceButtonHandler  clearanceHandler  =  new  clearanceButtonHandler(); 
clearanceButton.addActionListener(  clearanceHandler  ); 

/*  * 

*  This  part  displays  the  "AVAIES"  logo  on  the  top  of  the  console. 

*/ 

Icon  logo  =  new  ImageIcon(  "top_logo3.gif'  ); 
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Iabel2  =  new  JLabelQ; 
label2.setIcon(  logo ); 

label2.setHorizontalTextPosition(  SwingConstants. CENTER  ); 

northPanel.add(  label2  ); 

c.add(  northPanel,  BorderEayout.NORTH  ); 

//east  panel  construction 
eastPanel.setEayout(  new  GridLayout(  3,1)); 
eastPanel.add(  weatherSetButton  ); 
eastPanel.add(  resetButton ); 
eastPanel.add(  onOffButton  ); 
c.add(  eastPanel,  BorderEayout.EAST  ); 

//east  panel  button  handlers 

weatherButtonHandler  weather SetHandler  =  new  weatherButtonHandler(); 
weatherSetButton.addActionEistener(  weather  SetHandler  ); 
resetButtonHandler  resetHandler  =  new  resetButtonHandler(); 
resetButton.  addActionListener(  resetHandler  ); 
onOffButtonHandler  onOffHandler  =  new  onOflButtonHandler(); 
onOffButton. addActionEistener(  onOffHandler ); 

//the  message  box 
textButton  =  new  JButton(  ); 
messageDisplay  =  new  JTextPieldQ; 

//messageDisplay.setEditable(  false  ); 
textButton.add(  messageDisplay ); 

textButton.setHorizontalAlignment(  SwingConstants. CENTER  ); 

//south  panel  construction 
southPanel.setEayout(  new  GridLayout(  1,3)); 
southPanel.add(  clearButton ); 
southPanel.add(  textButton  ); 
southPanel.add(  notClearButton  ); 
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c.add(  southPanel,  BorderLay out. SOUTH  ); 


*  This  is  the  center  piece  of  the  console.  Currently,  there  is  only  a  ".gif' 

*  file  shown  on  the  display.  Ideally,  this  would  involve  some  degree  of  graphics 

*  simulation  and  represent  the  data  obtained  from  the  sensors  and  processed 

*  accordingly.  Sensor  coding  was  not  including  in  this  file  and  extends  beyond  the 

*  current  scope  of  this  thesis  which  was  to  conceptualize  the  AVAILS-HCI. 

* ! 

Icon  mainmap  =  new  ImageIcon(  "mainmap.gif '  ); 
centerButton  =  new  JButton(  mainmap  ); 

clearButton.setHorizontalAlignment(  SwingConstants. CENTER  ); 

centerPanel.add(  centerButton  ); 

c.add(  centerPanel,  BorderEay out. CENTER  ); 

//boolean  toggle  values 
modeSubMenuVisible  =  false; 
settingsSubMenuVisible  =  false; 
modeMenuVisible  =  false; 
weatherSettingsVisible  =  false; 


//set  panel  size 
setSize(  650,  600 ); 
show(); 

} 


*  The  main  method 

*/ 

public  static  void  main(  String  args[]  ) 
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{ 


MainDisplay  app  =  new  MainDisplay(); 

app .  addW  indo  wListener( 
new  Window AdapterO  { 
publie  void  windowClosing(  WindowEvent  e  ) 

{ 

System.  exit(  0 ); 

} 

} 

); 

}  //end  of  main 

*  This  button  opens  the  mode  sub  menu 

*/ 

private  elass  modeButtonHandler  implements  AetionListener  { 
publie  void  actionPerformed(  ActionEvent  e  ) 

{ 

//wasModeSeleetedEirst  =  false; 

ModeSubMenu  msm  =  new  ModeSubMenu(); 
//msm.showO; 

modeSubMenuVisible  =  ImodeSubMenuVisible; 
msm.setVisible(  modeSubMenuVisible ); 
if  (ImodeSubMenuVisible) 

{ 

getContentPane().repaint(); 

} 

} 

}  //end  of  buttonhandler 

*  This  button  opens  the  settingssubmenu 
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*/ 

private  class  settingsButtonHandler  implements  ActionListener  { 
public  void  actionPerformed(  ActionEvent  e  ) 

{ 

SettingsSubMenu  ssm  =  new  SettingsSubMenu(); 
//msm.showO; 

settingsSubMenuVisible  =  IsettingsSubMenuVisible; 
ssm.setVisible(  settingsSubMenuVisible ); 
if  (IsettingsSubMenuVisible) 

{ 

getContentPane().repaint(); 

} 

} 

}  //end  of  buttonhandler 

*  This  button  would  display  the  front  and  rear  clearances 

V 

private  class  clearanceButtonHandler  implements  ActionListener  { 
public  void  actionPerformed(  ActionEvent  e  ) 

{ 

JOptionPane.showMessageDialog(  null, 

"Button  Pressed." ); 

} 

}  //end  of  buttonhandler 

*  This  button  opens  the  weathersettings  menu 

V 

private  class  weatherButtonHandler  implements  ActionListener  { 
public  void  actionPerformed(  ActionEvent  e  ) 

{ 

Weathers  election  ws  =  new  WeatherSelection(); 
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//msm.showO; 

weatherSettingsVisible  =  IweatherSettingsVisible; 
ws.setVisible(  weatberSettingsVisible ); 
if  (IweatberSettingsVisible) 

{ 

getContentPane().repaint(); 

} 

} 

}  //end  of  buttonbandler 

*  This  button  handler  ideally  would  clear  all  prior  settings 

*/ 

private  class  resetButtonHandler  implements  ActionListener  { 
public  void  actionPerformed(  ActionEvent  e  ) 

{ 

JOptionPane.sbowMessageDialog(  null, 

"Options  Cleared." ); 

} 

}  //end  of  buttonbandler 

*  This  button  handler  turns  the  system  off 

*/ 

private  class  onOffButtonHandler  implements  ActionListener  { 
public  void  actionPerformed(  ActionEvent  e  ) 

{ 

System.exit(  0 ); 

} 

}  //end  of  buttonbandler 
}  // end  of  MainDisplay  java 
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2.  The  Mode-Sub-Menu  file  allows  the  user  to  ehoose  between  the  “Park”  and 


“Travel”  modes. 

*  File;  ModedSubMenu.java 

*  Harold  M  Mosley 

*  AVAILS  Code  -  AVAILS-  HCI 

*  Thesis  Appendix 

*  Semptember  20,  2001 

*  This  file  presents  the  user  with  the  mode  sub  menu,  which  list  the  "park"  and 

*  "travel"  modes  to  the  user.  This  is  a  generic  implementation. 

V 

import  java. io.*; 
importjava.net.*; 
import  j  ava.awt.  * ; 
import  j  ava.  awt.  event.  * ; 
import  j  avax . swing .  * ; 

public  class  ModeSubMenu  extends  JFrame  { 
private  JPanel  centerPanel; 
private  JButton  parkButton,  travelButton; 
private  Color  pb; 

private  boolean  parkModeWasSelected  =  false; 
private  boolean  travelModeWasSelected  =  false; 

//constructor 
public  ModeSubMenuO 
{ 

super(  "Mode  Sub-Menu" ); 

Container  c  =  getContentPane(); 

//create  panels 
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centerPanel  =  new  JPanel(); 


//create  buttons  for  the  panel 
parkButton  =  new  JButton("Parking"); 
parkButton.setBackground(  pb.yellow  ); 
travelButton  =  new  JButton(  "Traveling"  ); 
travelButton.setBackground(  pb.yellow  ); 

//center  panel  layout 
centerPanel. add(  parkButton  ); 
centerPanel. add(  travelButton  ); 
centerPanel. setLayout(  new  GridLayout(  2,1  )); 
c.add(  centerPanel,  BorderLay out. CENTER  ); 

//create  buttonhandlers 

parkButtonHandler  parkModeHandler  =  new  parkButtonHandler(); 
parkButton.addActionListener(  parkModeHandler  ); 
travelButtonHandler  travelModcHandler  =  new  travelButtonHandler(); 
travelButton.addActionListener(  travelModcHandler ); 

//set  panel  size 
setSize(  180,  250 ); 
show(); 

}//  end  constructor 

*  The  main  method  was  only  used  to  independently  test  the  compilation  of  this  file 

*/ 

public  static  void  main(  String  args[]  ) 

{ 

ModeSubMenu  app  =  new  ModeSubMenu(); 
app .  addW  indowEistener( 
new  Window AdapterO  { 
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public  void  windowCIosing(  WindowEvent  e  ) 

{ 

System.  exit(  0 ); 

} 

} 

); 

}  //end  of  main 

*  This  button  handler  sets  the  sensors  to  detect  near  objeets.  The  idea  here 

*  is  to  relay  to  the  driver  that  he  is  in  park  mode. 

*/ 

private  elass  parkButtonHandler  implements  AetionListener  { 
publie  void  aotionPerformed(  AetionEvent  e  ) 

{ 

JOptionPane.showMessageDialog(  null, 

"All  Sensors  are  set  for  near  deteetion;  .5  to  3  Peet.\n"  + 

"You  may  now  park!"  ); 
parkModeWasSeleeted  =  true; 

} 

}  //end  of  parkButtonHandler 

*  This  button  handler  takes  the  user  to  the  settings  menus.  Onee  the  travel 

*  mode  has  been  seleeted,  the  user  must  deeide  if  they  want  default  distanees 

*  or  if  they  would  like  to  enter  their  own  distanees. 

*/ 

private  elass  travelButtonHandler  implements  AetionEistener  { 
publie  void  aotionPerformed(  AetionEvent  e  ) 

{ 


JOptionPane.showMessageDialog(  null, 

"You  must  now  seleet  an  option  from  the  [Settings]  Button."  ); 
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SettingsSubMenu  setsm  =  new  SettingsSubMenu(); 
setsm.showQ; 

travelModeWasSelected  =  true; 

} 

}  //end  of  travelButtonHandler 
}  // end  of  ModeSubMenu.java 
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3.  The  SettingsSubMenu  file  allows  the  user  to  select  either  the  “Default”  or 
“User”  options: 

*  File:  SettingsSubMenu.java 

*  Harold  M  Mosley 

*  AVAILS  Code  -  AVAILS-  HCI 

*  Thesis  Appendix 

*  Semptember  20,  2001 

*  This  file  presents  the  user  with  the  "user"  and  "default"  settings  options.  It 

*  is  here  that  the  user  can  either  use  default  settings  or  input  their  own  distances. 

V 

import  java. io.*; 
importjava.net.*; 
import  j  ava.awt.  * ; 
import  j  ava.  awt.  event.  * ; 
import  j  avax . swing .  * ; 

public  class  SettingsSubMenu  extends  JFrame  { 
private  JPanel  centerPanel; 
private  JButton  defaultButton,  userButton; 
private  Color  pb; 

//constructor 

public  SettingsSubMenuO 

{ 

super(  "Settings  Sub-Menu"  ); 

Container  c  =  getContentPane(); 

//create  panels 
centerPanel  =  new  JPanel(); 
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//create  panels 

defaultButton  =  new  JButton(  "Default"  ); 
defaultButton.setBackground(  pb. green  ); 
userButton  =  new  JButton(  "USER"  ); 
userButton.setBackground(  pb.green  ); 

//center  panel  layout 
centerPanel.add(  defaultButton  ); 
oenterPanel.add(  userButton  ); 
centerPanel.setLayout(  new  GridLayout(  2,1  )); 
c.add(  centerPanel,  BorderLay out. CENTER  ); 

//ereate  buttonhandlers 

defaultButtonHandler  defaultModeHandler  =  new  defaultButtonHandler(); 
defaultButton.addAetionListener(  defaultModeHandler ); 
userButtonHandler  userModeHandler  =  new  userButtonHandler(); 
userButton.  addAetionListener(  userModeHandler  ); 

//set  panel  size 
setSize(  180,  250 ); 
show(); 

}//  end  constructor 

*  The  main  method  was  used  to  independently  test  the  compilation  of  this  file 

*/ 

publie  static  void  main(  String  args[]  ) 

{ 

SettingsSubMenu  app  =  new  SettingsSubMenu(); 
app .  addW  indowEistener( 
new  Window AdapterO  { 
public  void  wmdowClosmg(  WindowEvent  e  ) 

{ 
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System.  exit(  0 ); 

} 

} 

); 

}  //end  of  main 

*  This  button  handler  implements  the  default  option 

*/ 

private  class  defaultButtonHandler  implements  ActionListener  { 
public  void  actionPerformed(  ActionEvent  e  ) 

{ 

JOptionPane.showMessageDialog(  null, 

"All  weather  settings  will  be  set  at  default  values.  Thank  you."  ); 

} 

}  //end  of  buttonhandler 

/=t=H= 

*  This  button  handler  implements  the  user  option 

*/ 

private  class  userButtonHandler  implements  ActionListener  { 
public  void  actionPerformed(  ActionEvent  e  ) 

{ 

JOptionPane.showMessageDialog(  null, 

"Please  select  the  weather  condition  that  you  will\n"  + 

"be  driving  in,  from  the  Weather  Settings  Button."  ); 

Weathers  election  ws  =  new  WeatherSelectionQ; 
ws.showO; 

} 

}  //end  of  buttonhandler 
}  //  end  SettingsSubMenu  class 
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4.  The  Speed-Menu  file  lists  the  vehicle  separation  distances  for  the  user. 


*  File:  SpeedMenu.java 

*  Harold  M  Mosley 

*  AVAILS  Code  -  AVAILS-  HCI 

*  Thesis  Appendix 

*  Semptember  20,  2001 

*  This  tile  merely  lists  the  available  speed  limits 

V 

import  j  ava.awt.  * ; 
import  j  ava.  awt.  event.  * ; 
import  j  avax . swing .  * ; 
import  j  avax .  swing  .event.  * ; 
public  class  SpeedMenu  extends  JFrame  { 
private  JList  speedList; 
private  Container  c; 
private  Color  col; 

/* 

*  The  following  speed  limits  are  presented  on  a  list  for  the  user  to  select 

*  appropriately  the  selected  object  would  be  used  throughout  the  life  time  of  the 

*  current  settings 

V 


private  String  speedLimits[]  = 

{  "30",  "35",  "40",  "45",  "50",  "55",  "60",  "65", 
"70",  "75",  "80",  "85"  }; 


//constrcutor 
public  SpeedMenuO 
{ 


super(  "Speed  Limits" ); 
c  =  getContentPaneO; 
c.setLayout(  new  FlowLayout()  ); 
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speedList  =  new  JList(  speedLimits  ); 
speedList.setVisibleRowCount(  8 ); 

speedList.setSelectionMode(  ListSelectionModel.SINGLE  SELECTION ); 
c.setBackground(  col.darkGray  ); 
c.add(  new  JSerollPane(  speedList ) ); 

speedList.addListSelectionListener( 
new  Lists  eleetionListenerQ  { 
public  void  valueChanged(  ListSelectionEvent  e  ) 

{ 

JOptionPane.showMessageDialog(  null, 

"Thank  you,  safe  driving!"  ); 

} 

} 

); 

setSize(  210,  200 ); 
show(); 

}//  end  constructor 

//This  main  section  was  used  to  independently  test  the  implementatio  of  this  file 
public  static  void  main(  String  args[]  ) 

{ 

SpeedMenu  app  =  new  SpeedMenu(); 
app .  addWindowListener( 
new  Window AdapterO  { 
public  void  windowClosing(  WindowEvent  e  ) 

{ 

System.exit(  0 ); 

} 

} 

); 

}//  end  of  main 
}//  end  of  SpeedMenu  class 
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5.  The  Weather-Selection  file  allows  the  user  to  select  the  current  weather 


condition  under  which  they  will  be  operating  their  vehicle.  The  code  only  represents  a 
generic  implementation  of  the  weather  selection  list. 

*  File;  WeatherSelection.java 

*  Harold  M  Mosley 

*  AVAILS  Code  -  AVAILS-  HCI 

*  Thesis  Appendix 

*  Semptember  20,  2001 

*  This  file  only  list  the  weather  conditions  that  the  user  can  select  from  the  menu. 

V 

import  j  ava.awt.  * ; 
import  j  ava.  awt.  event.  * ; 
import  j  avax . swing .  * ; 
import  j  avax .  swing  .event.  * ; 

public  class  WeatherSelection  extends  JFrame  { 
private  JList  climateList; 
private  Container  c; 
private  Color  col; 

SpeedMenu  sm  =  new  SpeedMenu(); 

MainDisplay  md  =  new  MainDisplayO; 

//These  are  the  current  weather  selections 

private  String  weaConditions[]  ={  "Daytime",  "Darkness",  "Rain",  "Fog",  "Snow"  }; 

public  WeatherSelection() 

{ 

super(  "Weather  Settings" ); 
c  =  getContentPaneO; 
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c.setLayout(  new  FlowLayout()  ); 
climateList  =  new  JList(  weaConditions  ); 
climateList.setVisibleRowCount(  3  ); 

climateList.setSeleetionMode(ListSelectionModel.SINGLE_SELECTION ); 

c.setBackground(  col. orange  ); 

c.add(  new  JScrollPane(  climateEist )  ); 

/* 

*  The  idea  here  is  show  the  user  confirmation  that  their  selection  was 

*  indeed  entered.  This  is  just  a  generic  confirmation.  Actual  imple 

*  mentation  would  take  the  value  selected  and  show  the  value  to  the  user 

*/ 

climateEist.addListSelectionListener( 
new  EistSelectionListenerO  { 
public  void  valueChanged(  EistSelectionEvent  e ) 

{ 

JOptionPane.showMessageDialog(  null, 

"Weather  condition  entered.\n"  + 

"Now  select  your  desired  passing/trailing  distance." ); 

sm.show(); 

md.repaintO; 

} 

} 

); 

setSize(  250,  100 ); 
show(); 

}  //  end  Weathers  election  constructor 

//This  main  section  was  used  to  independently  test  the  implementatio  of  this  file 
public  static  void  main(  String  args[]  ) 

{ 

WeatherSelection  app  =  new  WeatherSelection(); 
app .  addWindowEistener( 
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new  Window AdapterO  { 
public  void  windowClosing(  WindowEvent  e  ) 
{ 

System.exit(  0 ); 

} 

} 

); 

}//  end  main 

}//end  of  WeatherSelection  class 
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